search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.49k stars 280 forks source link

Please improve SPI flash instructions/script #350

Open TurkeyMan opened 2 years ago

TurkeyMan commented 2 years ago

After an awful lot of stuffing around with failing UART flashing (fails at 2 bars trying to erase), I managed to accidentally break the TX/RX pads off the module. I'd like to flash with SPI, but the instructions are really thin. Please improve the SPI instructions; please make the steps a bit more concrete so if I follow the instructions, it will work. Please note which image file should be used when performing an SPI flash? The example shows a QIO image, but there is no such image for BK7231T, only the UA image. It says stuff about recovering bootloader and stuff... I don't think that's necessary in normal cases? I'm using a PI4 to attempt flashing.

openshwprojects commented 2 years ago

Do you have a device with SPI pins broken out?

TurkeyMan commented 2 years ago

Yes it's WB3S, I can break out the SPI pins easily, I haven't damaged those pads ;)

On an unrelated note, I noted a strange behaviour I haven't seen mentioned anywhere; when I short CEN to GND which I'm told to reset the chip before UART flashing, I had a very odd issue where the pi4 would immediately reboot. 3.3, GND, TX, RX were connected to the pi4, but when I bridge CEN to GND, it immediately reboots the pi. Ever seen this?

openshwprojects commented 2 years ago

No. My Banana Pi has never rebooted during BK7231 flashing.

I flashed BK7231T with SPI mode almost few days ago, but I wrote the tool myself: https://github.com/openshwprojects/BK7231_SPI_Flasher

Can you try that one?

iprak commented 2 years ago

I too have a candidate chip which could use this.

I had tried SPI using https://github.com/btsimonh/hid_download_py/blob/master/rpi3install.md but the chip has always been unresponsive. Are the connections same as https://github.com/btsimonh/hid_download_py/blob/master/SPIFlash.md ?

openshwprojects commented 2 years ago

@iprak connections are the same, except the pin for CEN, which can be any digital IO and you have to adjust it in the Python code.

My code work for 100% with T, I tested it few days ago. I was not able to get the original hid_download_py SPI version running.

BTW: if you get SPI flashing running, make some photos and post a short report to Elektroda. Not much people do SPI flashing for Beken and you'd be one of the firsts.

TurkeyMan commented 2 years ago

Does the pi have shell commands to set the state of GPIO's, and/or send/recv packets via SPI? Can I cat TEXT > /dev/spi0.0 or something like that? I can't find anyway to interact with these devices from linux, it always seems to be python.

I tried your BK7231_SPI_Flasher script, but it errored immediately on this line CENGPIO = GPIO.PB+21 complaining that GPIO.PB was not among GPIO...

If I continue beating at that script trying to make it work, it's not clear what image to write, and also how to write it... There's a bunch of code like this:

# this will allow you to write directly bootloader + app
#WriteImage(0,"OpenBK7231T_App_QIO_35a81303.bin", 0x200000)
# if you have an app that was loaded by bkWriter 1.60 with offs 0x11000,
# and you have broke your bootloader, you can take bootloader from OBK build
# and then restore an app
WriteImage(0,"OpenBK7231T_App_QIO_35a81303.bin", 0x11000)
WriteImage(0x11000,"REST.bin", 0x200000)
# I used this to verify my code and it work
#ReadStart(0,"tstReadS.bin", 0x1100)

You show a QIO image here, but I didn't see any images like that for the T, there's only one for the N, and I thought they were totally different? There's also REST.bin, what is that? It's not among the release images... Should I uncomment the first line? But which image file to write?

It's be great if this script were improved to be a little more helpful and perhaps check for setup errors if possible in advance? Possible for the script to test if reset works? Test if SPI is actually wired correctly and communicating?

iprak commented 2 years ago

Yup I get the same on RaspberryPi3b

TurkeyMan commented 2 years ago

Yup I get the same on RaspberryPi3b

Got the same what?

TurkeyMan commented 2 years ago

@iprak connections are the same, except the pin for CEN, which can be any digital IO and you have to adjust it in the Python code.

Your code shows GPIO.PB + 21, what does this mean? Is it pin 1 + 21 (== GPIO22??) or are you using GPIO21? I wired to GPIO22 following some other instructions I saw elsewhere, and I wasn't clear if your script was correct or if I should change 21 to 22...?

My code work for 100% with T, I tested it few days ago. I was not able to get the original hid_download_py SPI version running.

If it worked with T, where did you get this QIO image? What is it? That image doesn't exist... It's confusing to have your script compete with the hid_download_py version, perhaps you could improve the other script and make it work better, with some command line options, help text, more verification checks along the way, etc? It's obviously less mature than the UART script, but ideally, both scripts should maintain a feature parity and become more foolproof.

BTW: if you get SPI flashing running, make some photos and post a short report to Elektroda. Not much people do SPI flashing for Beken and you'd be one of the firsts.

I'm happy to do this if I can make it work. Currently I can't even determine if the SPI comms is enabled and working at all. It'd be great if you can enhance the script to initially confirm SPI comms is actually working... is it possible to make a confirmation while the stock tuya/smartlife firmware is booted and running, or can you only detect this immediately after a reset?

For someone using a pi for flashing, no reason SPI should be any harder than UART; only difference is SPI needs 4 wire breakout rather than 2... but in theory they should both be equally simple?

openshwprojects commented 2 years ago

@TurkeyMan I have a guide that is halfway ready. I think the fastest way for you would be to wait for it, or.... or trying google, because enabling SPI coms on Pi is a generic PI knowledge, not an openBeken related one.

On other hand, the missing QIO file is a very good question! IT was never intended for users to flash by SPI, because we didn't even know if it's possible. We shall modify our release script to output QIO. UPDATE: https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.14.78

REST.bin is a file that was read by bkWriter 1.60 from the offset 0x11000.

TurkeyMan commented 2 years ago

.... or trying google, because enabling SPI coms on Pi is a generic PI knowledge, not an openBeken related one.

Yes, I followed instruction for enabling SPI on pi. That's not a problem, but I have no way to verify that it's working. Maybe SPI is working and the problem is something later like waiting for reset, or maybe SPI is not working and I have a wiring fault, or maybe I just didn't enable it correctly. If there is any way to determine and distinguish each of these cases, it would be really good to add those step-by-step checks to the script at the start and write error messages explaining what the problem is for each step so it can be corrected. This will allow many more people to be successful using your software. I think software can detect if pi's SPI is enabled before trying to use it, if not, the user can research how to enable it themselves... but hopefully it would be an easy first check.

On other hand, the missing QIO file is a very good question! IT was never intended for users to flash by SPI, because we didn't even know if it's possible. We shall modify our release script to output QIO. UPDATE: https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.14.78

Oh great. I saw in the release notes that for T the UA file says UART flash, and for N the QIO file says UART flash... it made me think UA/QIO must mean something else and both images are for UART (and maybe SPI uses same image as UART?)... but what you said here means maybe that's wrong, and the information written in the release table might need to be updated?

REST.bin is a file that was read by bkWriter 1.60 from the offset 0x11000.

Do I need this to flash from stock to OpenBK?

TurkeyMan commented 2 years ago

Update: just saw the releases QIO update. Thanks for that! Can you please add a couple sentences explaining the UA/QIO images, what they actually are? Why are they different? You explained "CCtr" at the bottom, just add a line for each other one to explain what it's for. I notice that N only has QIO image, but it still says "UART Flash" beside it... is that wrong?

TurkeyMan commented 2 years ago

when I short CEN to GND which I'm told to reset the chip before UART flashing, the pi4 would immediately reboot

Do you think this might be an electrical problem? Is it possible that connecting CEN to a GND pin in the GPIO bank will create a high current short circuit and trip some circuit protection resetting the pi? I also noticed when using a USB TTL adapter on Windows, that when I connect CEN to the TTL GND pin, the USB device would immediately be disconnected from windows, and it would come back and windows re-detect the device, playing the new USB connection sound when releasing the connection. My guess is that maybe the PC USB bus was protecting itself from over-current by disabling the device, and the pi is experiencing a similar effect? Should there be a resistor between CEN and GND perhaps?

leoshusar commented 2 years ago

I used hid_download_py and simply this command:

python ./spiprogram -w ../OpenBK7231T_UA_1.14.34.bin

I wasn't successful with the reset pin, so I ran the flash command and reconnected VCC. Tried a few times (maybe 2 or 3) and then it connected and went great.

But it's soooo slow to flash the whole FW, it took I think 10 to 15 minutes. Maybe you might be able to flash only the bootloader section of the FW and then use UART for complete reflash.

To the Windows reconnecting - USB power might be the case. I wasn't able to flash FW via UART using USB-UART adapter, it was going up to 78 % and then just fail. Sometimes less, with higher speeds even less. Then I powered the chip from another power source and used the same UART adapter, connected just TX, RX and GND and immediately flashed successfully even on highest speed.

TurkeyMan commented 2 years ago

@leoshusar Okay, following those instructions it started working.

SPI flashj jig: image

And it was flashing (kinda slow; not 10-15 minutes, more like 5 minutes), but then it locked up at 88%

image

Now it just sits there stuck, not progressing. Guess I'll have to re-power and hope it didn't destroy the bootloader so I can try again...

TurkeyMan commented 2 years ago

Okay, it got to 100%, flashing with:

python3 ./spiprogram -w ../OpenBK7231T_QIO_1.15.27.bin

I guess that means it worked? I tried to follow the first boot instructions, it didn't seem to find anything from the tuya flash, it did not connect to the AP, so I turned it off/on/off/on/etc a bunch of times, but an AP never appears... I have no idea how I can determine if the chip is powered properly, is attempting to boot, what might be going wrong? Any suggestions?

Perhaps the spiprogram script could be improved to read back the image and verify it's written correctly so at least I can be sure it flashed correctly?

TurkeyMan commented 2 years ago

I decided to wire up TX2, and and cat /dev/ttyS0. It dumps this, over and over extremely quickly:

V:BK7231S_1.0.5
CPSR:000000D3
R0:3A412331
R1:BD57917F
R2:8D87357B
R3:69A323FD
R4:5EA070EB
R13:5BE6FFBF
R14(LR):FCFE6EBD
ST:0B3932D9
J 0x10000

V:BK7231S_1.0.5
CPSR:000000D3
R0:00000000
R1:00DFFEFC
R2:00802000
R3:F1CCFFFF
R4:00010000
R13:0043F7C8
R14(LR):0000BCBC
ST:BEDEAD01
J 0x10000

... repeats ...

Looks like a crash dump. The values are different on power-on, but then they repeat the second set of values infinitely after power on. ST:BEDEAD01 looks like a suspicious stack pointer!

So... what might have gone wrong? Any idea how I can diagnose/recover this chip?

leoshusar commented 2 years ago

Try to SPI flash UA release.

QIO means Quad IO, that's number of IO lines talking to the flash memory, so I think it should be used for SPI, but I don't know, I didn't even try QIO, I just straight tried UA and it worked.

...

QIO means Quad IO

at least for ESP. This is written in Tuya docs: image

and I don't really understand what they mean by user area and production firmware.

TurkeyMan commented 2 years ago

Yes, I have another issue lodged elsewhere to improve the readme to explain what UA/QIO image difference actually is, and when/why you need one or the other.

Okay, I'll try and flash the UA one instead...

EDIT: are you sure? The QIO image is exactly 1MB, but the UA image is only 956KB... shouldn't the image to flash be the right size? What size was the image you flashed? Perhaps you can paste a copy of the image you successfully flashed?

TurkeyMan commented 2 years ago

Huzzah! Flashing the UA firmware boots and works; it creates an AP I can connect to as expected in recovery mode.

Okay, so all the SPI material floating around mentioned QIO images, but in my case that was incorrect, and I needed to flash the UA firmware.