The 'downloader' can read/write but also unpackage/decrypt original firmware.
The SDK is a 'light touch' modified SDK (including @p.kaczmarek2 mods and samples, although his samples won't work without tuya lib), but removes the tuya lib, and my sample worked (to some degree) with no tuya involved. Still needs cygwin....
As my devices is now dead, my dev stops for a while. If anyone thinks an STLink can program these chips, pls. point me in the right direction! Br, btsimonh
I think there is something in wifi configuration not getting done at startup - there is some form of exception in the log at startup (same as when it was not authenticating), but then it connects after that fine. On the MQTT rx, it just reboots when a message is sent on that topic. I assume it's likely a threading issue/invalid memory access - that IP library is not thread safe apparently. Also, mine reported as a BK7231S chip, so it may have some differences.
Let me know if you get any success with an STLink - I have one somewhere. And pls read your bootloader (either via STLink if you can, or from firmware - just setup a TCP server and when connected to spout the flash content at the person who connected, then collect this in something like NodeRed?) - we can compare to the bootloaders in the SDK.
@btsimonh how are you powering the module for testing? I've found that the 3v3 supply from my CH340G can't deliver the current the module needs for wifi and the chip was browning out and resetting.
It seems pretty sensitive to voltage actually, based on min-max from the DMM it seems that it browns out around only 3.19-3.2V.
Using a PI2/3/4 for 3v3 and uart solves this problem as they have a beefy 500mA switching regulator.
Mine had 12V input.... so I ran the gnd to the 2 x serial adaptors, plus the 4 serial lines only. Then used the 12v to power the board. (Calex LED strip controller).
I would be very interested if anyone tries the CTS (or RTS? can't remember; check the python repo to see what it sets) connected to CS, to see if this resets the board for flashing?
@btsimonh how are you powering the module for testing? I've found that the 3v3 supply from my CH340G can't deliver the current the module needs for wifi and the chip was browning out and resetting.
C'mon people, I emphasized several times in my tutorial (here, and in XR809 case, and in polish one related to TYWE2S) that using 3.3V directly from USB to TTL converter was not working for me. Or didn't I?
I didn't investigate it much but I just assumed that 5V and 3.3V pins of my USB to TTL are just to select 3.3V or 5V UART levels, they are not intented to power external circuits.
btsimonh wrote:
And pls read your bootloader (either via STLink if you can, or from firmware - just setup a TCP server and when connected to spout the flash content at the person who connected, then collect this in something like NodeRed?) - we can compare to the bootloaders in the SDK.
I assume that you've tested the flash write and read API in the current SDK?
Btw, where is your chip-breaking "http_flash_init"? There is also no "http_wr_to_flash", you must have forgoten one file. I wanted to check this one, since I have several chips (thanks to @PIXELLO) and I can freely brick them if I want to. I am not able to help you when I can't see the flash update code.
EDIT: Found it, utils_httpc.c
It will take some precise soldering to break out all of these chips.
I assume that you've tested the flash write and read API in the current SDK?
HaHa! You assume far too much . No, I stupidly trusted that it may work, and was so elated that your TCP server worked, just went for it, to my cost.
So... yes, be careful with flash, not careless like me. It MAY have worked if I was not also trying to bk_printf all received data at the same time!
I found some interesting beken related SPI info here: https://mitxela.com/forum/topic/beken-bk3231/2 - 'same same but different' chip? - so tempted to dig out an esp8266 and try.
t MAY have worked if I was not also trying to bk_printf all received data at the same time!
I'd rather say that it had 0 chances of working correctly. If I understand well, you used Tuya bootloader to upload your (mine) modified TCP server code to BK User Area memory section, and then... then tried to use code from User Area to update User Area?
It is impossible to do that without an external buffer, it's like doing a russian roulette with machine code, at one point your remote update starts overwriting currently executed code and ultimately it ends up executing random instructions leading up to random errors.
You can only do that if you place your bootloader code in the separate memory section that the one you're updating.
So I started to work on one of donated WB2S modules:
Ok, I think I took an overly complicated approach but it works:
Here is the debug log from the original tuya module:
tuya_origi..._uart2.txt Download (5.83 kB) Here is the original firmware (but I think it starts at offset 0x11000 and has size of 0x00200000 bytes, it's impossible to read the bootloader itself by using Beken Writer V1.60):
tuya_origi...m_wb2s.zip Download (5.86 MB) You can try to decrypt it if you want.
I will try it soon, so if you have any suggestions or ideas, voice them now. I'd rather avoid bricking module which took so much tricky soldering.
EDIT: Important hint for BKwriter1.60 users! If you're getting Failed while programming (but after erase, so chip don't boot anymore), try changing baud rate, sometimes changing even from lower to higher baud helps!
EDIT2: added en.stsw-link009_v2.0.2.zip (stlink usb driver for windows) and stlink-1.7.0-x86_64-w64-mingw32.zip (st-flash.exe for windows)
ohhh... looking promising.
Do you believe the firmware built by the alios SDK includes the bootloader? the stlink command line is flashing to 0x08000000, which to me means it's writing to the start of flash . But looking at the alios SDK, I can't find where it combines the bootloader and the build output . Maybe attach the output .bin file here?
I believe if the bootloader is included, you should find an 'RBL' block at 0x10000, and the start of the actual app at 0x11000. And the app should be encrypted and have the extra 2 bytes (crc?) every 32.
Over uart, you CAN read the RBL block at 0x10000, just realised why.. this is described as 'boot information' in https://github.com/bekencorp/bk7231_alios_sdk/blob/master/board/bk7231devkitc/board.c Also notable that the alios SDK does not include package.exe or encrypt.exe, so far as I can see by looking at github (although their search of the repo does seem compromised)...
I have an stlinkv2, just need to dig it out of my hoverboard.... and work out the connections. On the hoverboard I thought it was using an SWD flash method, but I may be wrong.
From the beken bk7231 manual, we have JTAG pins.
I have P20/P21/P22, and ADC3 is P23: (note, these are PORT numbers, not PIN numbers).
However, reading more about JTAG, the flashing procedures are very manufacturer dependent - some involving loading a flashing subroutine into ram, some calling a flashing subroutine in mask ROM... I am not hopeful .
will be interested in your thoughts/findings.... searching for my stlink now....
br,
Simon
ohhh... looking promising.
Do you believe the firmware built by the alios SDK includes the bootloader?
I rather hoped that we will be able to read the bootloader from another Tuya module.
btsimonh wrote:
Also notable that the alios SDK does not include package.exe or encrypt.exe
I think that package.exe and encrypt.exe might be a bit more tuya-specific and are used only while flashing by UART bootloader, not while by SPI? But it's just a guess
btsimonh wrote:
far as I can see by looking at github (although their search of the repo does seem compromised)...
Have you tried installing that SDK? It installs some things on the fly, that's why things seems to be missing from their git repo.
I will need to install it again as well, because I lost my ubuntu virtual machine with that.
I've did multiple attempts with ST-Link V2, but no results so far.
First I had to install ST-Link V2 drivers, which seems to be correct, but I haven't tested them with any devices because I have nothing that I cam flash with ST-Link V2 at hand.
I used those pins:
I have verified connection with multimeter (you can do that with diode test showing voltage drop, because the MCU IO is connected to VDD/GND by protection diodes).
I also tried with CEN pulled up and down.
You can see the commands I used in the logs below.
W:\Tuya\stlink-1.7.0-x86_64-w64-mingw32\stlink-1.7.0-x86_64-w64-mingw32\bin>st-flash.exe read test.bin 0x0 0x10
st-flash 1.7.0
libusb: info [winusb_get_device_list] The following device has no driver: 'USB\VID_0483&PID_3748\5&16BDD27B&0&5'
libusb: info [winusb_get_device_list] libusb will not be able to access it
libusb: info [winusb_get_device_list] The following device has no driver: 'USB\VID_8087&PID_0A2B\5&16BDD27B&0&9'
libusb: info [winusb_get_device_list] libusb will not be able to access it
2022-01-22T23:33:31 WARN usb.c: Couldn't find any ST-Link devices
libusb: warning [libusb_exit] some libusb_devices were leaked
W:\Tuya\stlink-1.7.0-x86_64-w64-mingw32\stlink-1.7.0-x86_64-w64-mingw32\bin>st-flash.exe read test.bin 0x0 0x10
st-flash 1.7.0
libusb: info [winusb_get_device_list] The following device has no driver: 'USB\VID_8087&PID_0A2B\5&16BDD27B&0&9'
libusb: info [winusb_get_device_list] libusb will not be able to access it
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
2022-01-22T23:41:18 ERROR common.c: Failed to read core_id
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2022-01-22T23:41:18 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target
W:\Tuya\stlink-1.7.0-x86_64-w64-mingw32\stlink-1.7.0-x86_64-w64-mingw32\bin>st-flash.exe --reset read test.bin 0x0 0x10
st-flash 1.7.0
libusb: info [winusb_get_device_list] The following device has no driver: 'USB\VID_8087&PID_0A2B\5&16BDD27B&0&9'
libusb: info [winusb_get_device_list] libusb will not be able to access it
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
2022-01-22T23:48:48 ERROR common.c: Failed to read core_id
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2022-01-22T23:48:48 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target
I can't say for sure that's not the correct way to go, but certainly it didn't work for me this time.
I will try again later with another module, maybe you can try as well?
So far I haven't tried the st-link binary that is installed with alios sdk, maybe they have modified version of one?
In a meantime, I might prepare better and more portable HTTP library
EDIT: don't get confused by "USB\VID_8087&PID_0A2B\5&16BDD27B&0&9" in my logs, this device without driver is not ST-link, it's something else on my USB bus
I'm looking at using my RPIZerow as a direct JTAG and SPI device, but failing to build OpenOCD because of stupid SSL issues on the Pi (old OS). I didn't want to do a fresh SD install, but may have to. In the mean time have tested all my pre-flashed-with-tasmota wall switches ready for installation next week. Bought Athom units.
I almost bought another Calex LED strip - Tescos in the UK has 'gone big' on stocking Calex tuya based devices. But I think understanding the unbricking procedure is my 'calling' for the moment.
hmm.. a thought. I may flash a ESP32 dev board with Espruino - that has SPI available . never used it, so good excuse to try....
I took your dump, @p.kaczmarek2, bk7231s_dump-2022- 1-21-21-20-20.bin and realized it also contains a bootloader starting at 0x1EF000. Can be decrypted using @btsimonh's method but replacing the last argument (start addr) with 0. It is the same one as the one available at [1].
hmm.. a thought. I may flash a ESP32 dev board with Espruino - that has SPI available . never used it, so good excuse to try....
Try it out, I am looking forward to seeing your test results! You could help me with testing when you unbrick your board.
Do you have a scope/logic analyzer?
Ok, the initial draft of my HTTP server is ready. I decided to write one from scratch because I didn't like the existing one:
(yes I know that strcat is unsafe, might update it to version respecting the output buffer size limit) Yes, you are seeing correct - I like that IDE. I really got used to it when I was working a lot in C/C++ and I am still using it after.... oh well, so many years. And I wrote that server on Windows.
It's a very nice portable setup, which also runs on WB2S:
It's using function wrappers and preprocessor to handle both platforms at once:
Testing HTTP server on Windows (without BK) makes everything easier and faster.
Futhermore, such a reusable server code with also allow me to run it on XR809:
https://www.elektroda.com/rtvforum/topic3806769.html So I will support BOTH chip families with one project.
This is the proud project main menu (as ran on WB2S):
It has WiFi creds form:
And this is the configurator:
You can have any number of relays, the buttons on the first page are generated automatically.
The physical button on the board is also supported, and also linked automatically:
It runs nicely on this WB2S board:
And it will run nice on that board as well:
Of course all the remaining processes are still on my TODO list, including MQTT support (using existing library, should be easy), the WiFi pass/ssid storage (in flash? I will have to look into it), etc, but the basics are done.
I will most likely prepare a short write-up/tutorial article soon (just like one in the first post), It will be showing the exact process and workings of my HTTP server. Then I will release current progress, and of course I will need testers. Anyone?
PS: Remember to support the project if you like: https://paypal.me/openshwprojects If you donated and want to be mentioned as a supporter in the thread/in the code, etc, send me a private message here
Looking forward to being able to run software and contribute again...
I fought with SPI for a lot of yesterday and 2 hours today - but I need to get my head in gear and check things properly... only in the last 10 mins of playing today did I realise I had all the connections wrong because my ribbon cable was folded... . Then I realised I'd been testing with the board not powered, so plugged in the 12v. Then I realised some minutes later that the wall-wart was not plugged in . (this is what it's like working with amateurs!!!).
So now I have the connections correct (?), but it's still not working. I draw encouragement from reports of someone else SPIing to a different Beken chip, so will continue. But now I don't know if I may have torched the chip completely or damaged the SPI pins...
Espruino seems to be unstable on ESP32, enough to play with maybe, but I'm not sure how well it will cope with actual flashing.
Did you try removing the Tuya lib and working without it yet?
Will be interested to see if the MQTT subscribe works for you, before and after removing the Tuya lib.
I also did not get http client to work. This would be good, at least for HTTP:, if not HTTPS:. It's a 'nice' way of doing OTA.
I'm fairly sure that DNS resolution was not operational in my without-tuya implementation, but also got connection failure with IP address only.
MQTT support works! Now I am able to control my relay (and virtually any simple-relays-based BK7231T module?) in 3 ways:
- by MQTT, for example from Home Assistant
- by a physical button on the module
- by my website which works in a similiar way to Tasmota's one
(I hope that whole video loads for you, there are still issues with our Elektroda movie player, I will try to use YT soon) As you can see, Home Assistant reacts immediatelly to me pressing physical button on WB2S module board, and WB2S module board reacts immediatelly to me clicking a HTML button on Home Assinstant page.
Soon I will be releasing a project update with a full code and step-by-step guide. And of course with documentation of my HTTP/pins management approach. It will be posted as separate topic on this forum.
btsimonh wrote:
Looking forward to being able to run software and contribute again...
The major hold up is the organisation of the workflow related to supporting both XR809 and BK7231,
I want my HTTP/pins/channels system backend (new_pins.c and new_http.c) to be used by both projects, because it will make maintaining both projects easier.
Right now I am not sure how I will organize that, at the moment my files are in my project app directory (it's nice that compiling scripts scan for all .c files in that dir automatically, I don't have to modify makefile) but in the end I might separate them.
Maybe I will end up with single repo containing both XR809 SDK and BK7231 SDK and one shared directory for my code.
I am slightly worried about confusing people with two separate projects in single repository, but maybe it's worth to do that... I want to "open" (as in open-source-firmware) as many chips as possible, and both XR809 and BK7231 will be compatible with HA and maybe much more soon.
Another hold up is the buttons organisation. Right now I am using Tasmota-like chip configuration where you can assign single function to each GPIO, but I also already have a working "short click", "double click" and "long hold" functions support for buttons. I must rethink how to organize that, maybe there is a better way to configure chip, some way that will allow me to assign multiple functions to single button.
For the record - I am thinking how to do this from an organisational standpoint, there are no problems with coding. I'm just trying to find some intuitive way for users to define that....
Or maybe I'm overthinking this and easy double click support is not so important and this stage of project.
btsimonh wrote:
Will be interested to see if the MQTT subscribe works for you, before and after removing the Tuya lib.
There was indeed a small crash related to reconnecting from the callback. It's fixed now.
btsimonh wrote:
I also did not get http client to work. This would be good, at least for HTTP:, if not HTTPS:. It's a 'nice' way of doing OTA.
What was the problem? Still, I wouldn't worry about it much. In the end it's relatively easy to write your own HTTP client
The next major TODO point on my list is to figure out how to save configuration in flash.
Hi, just in case someone else is struggling like me:
When i try to compile the mqtt demo I get:
../../../apps/my_mqtt_demo/src/tuya_device.c:59:19: fatal error: Error.h: No such file or directory
#include "Error.h"
By commenting it out I got things to run:
/* #include "Error.h" */
renaming to
#include "error.h" works as well.
I am eager to start testing your latest version - I have a curtain switch with touch sensor here where i switched to ESp and Tasmota.
@btsimonh: Your python flasher works on Linux? I hate having to use windows simultaneously..
Your python flasher works on Linux? I hate having to use windows simultaneously..
untested, but yes, it defaults to a linux USB device...
P.S. It's Beken's flasher, found by a guy above... I just updated it to read as well as write .
SPI Updates:
Seems that the key to getting to the SPI is to poke the Flash SPI pins shortly (within a few hundred ms) after a reset. This causes it to lock into a SPI flashing mode.
However, I'm yet to be successful in sending anything meaningful - not sure if it's the Espuino SPI at fault, so going to try from a RPI3b.
Hints are in the 'hidprogram' in that same python flasher - seems they send 250 'D2' bytes, then ask for the flash chip ID, possibly followed by a '06' 'chip enable'. We will see if I get any joy from RPI when it has a fresh new OS and is booting.
Dodano po 2 [godziny] 12 [minuty]:
Success with the SPI. Not flashed & running yet, but have read a flash ID (FLASH_ID_ESMT_25QH16B=0x0015701c), and am reading what remains of my corrupted flash now.
ESP32 SPI via Espruino was not doing the job. RPI3b SPI works, but not with rate > 50000 bits/sec.
Basic instructions:
Pull CEN down for 1 second. Immediately on raising it, send 250 'D2'. Then you can send the commands you want (e.g. 9f to get flash ID, 03 to read, 06 to enable write, etc.)
I guess the flash matches the data sheet for EN25QH16B in terms of commands - https://datasheetspdf.com/datasheet/EN25QH16B.html
GPIO control of CEN. All other lines 'normal' SPI lines.
Ok, now debricked... done for today.
To restore the bootloader, I flashed the first 0xf000 bytes from simon_light_pwm_demo_QIO_1.0.0.bin
That contains the 'encrypted' bootloader, but packaged, so it has the 32->34 byte expansion in it too...
Once I put that in place, it now boots - and runs my firmware which was undamaged .
I will write up the flashing tomorrow......
For my board, I'll need to add 5 x PWM and variable light controls to your app - so get that repo up soon .
p.s. it is tomorrow -
I've added to the python flashing github an SPIFlash.md and a prototype direct SPI flash reader/writer (untested). Will try to test tonight.
https://github.com/btsimonh/hid_download_py
p.p.s - ref wifi storage, we should document flash usage in the std firmware.
This is important because there is wifi calibration data, and one assumes the MAC address, in flash - which we will not want to overwrite or erase.
In the SPI flasher, I've set the default to only erase the sectors we are flashing to - the default previously was to erase the WHOLE device, which I would have thought would be bad from our perspective...
A 'safe' place to flash to may be the areas where you find references to logs. I'm pretty sure these are Tuya specific, and fairly large....
Also, the jlink config file is illuminating - it has register addresses relating to flash & CPU encryption/CRC maybe? This also indicates that JTAG is possible.
Best guess at the moment is that the JTAG pins become JTAG pins if 0.3v < CEN < 1v - i.e. if you fit a ~2k resistor to gnd on CEN, you may find JTAG will work. Found it in some odd Beken document...
I think there already might a place in the memory where the WiFi creds are stored because after my first flashing (by UART) my WB2S device that was paired to my WiFi by Tuya mobile application still remained connected to my network.
And it was connected there even after multiple firmware updates. I wrote about that some time ago in the XR809 topic, even before I posted this WB2S/BK7231T tutorial.
Also, it would be useful to find where the device name reporting to DHCP comes from, because in my case both WB2S/WB3S devices are seen by router as "wlan0".
EDIT: That's how they do this, just need to find a good position in memory
Code: c
Log in, to see the code
Maybe SSID_PASSWORD_TOKEN type?
Code: c
Log in, to see the code
Here's an open-access point setup method (working):
Code: c
Log in, to see the code
Here is a function to get MAC address (it's different slightly for AP and client modes) and use it to create unique device name:
Code: c
Log in, to see the code
Here is wlan0 name set:
ah, i see, net_dhcp_hostname_set
I will be reorganizing it more in the upcoming days, but you can already check this out and give your suggestions.
I will also make entire thing a bit more safe soon, for example, replace strcat with buffer-size-safe version.
I will also remove more of Tuya code, but I kept it still because I don't want to break something, I remove it line by line.
Do you have any ideas how to do configuration save in flash, or, to be specific, which flash offset should we use?
I'd suggest unpacking the original WB2S flash dump and checking where the vanilla Tuya firmware stored WiFi pass and ssid, and maybe we could even reuse it - image it, what a great feature, "device retains your wifi configuration from Tuya app, even after flashing with our firmware"!
I can send you some flash dumps from my WB modules for unpacking, if you have unpacker setup at hand. I realize that you might find out my WiFi SSID etc that way, but I don't expect you to visit Poland just to steal my slow web connection (just kidding).
PS: I am also actively searching for more devices to test, today I did DIGOO DG-S601 teardown, but sadly it has ESP8266 inside. What a shame. Anyway, you can read my teardown report here: https://www.elektroda.pl/rtvforum/topic3866386.html PS2: I need to remind myself where I put that WB3S LED strip dimmer, which I described there: https://www.elektroda.pl/rtvforum/topic3798114.html it's a next thing on my TODO list to be released from the Tuya/Beken closed source firmware chains.
Have you read out 0x1e1000, marked as BK_PARTITION_NET_PARAM? I haven’t had a chance to do it myself yet. It is a simple type-length-value structure that holds the wifi creds in the tuya SDK.
Is RPI SPI using 3.3V logic levels? I'm just asking to see if it would be possible to use simply cheap Arduino 5V-level clone for SPI communication.
yes, 3.3v. not sure what would happen with 5v....
I think most people looking into this would have ESP8266 or ESP32 to hand (all those TAS fans who bought devices only to find a WB2S inside....) , both of which have SPI at 3.3v - just a pity Espruino did not seem to work. It's great for that 'no compile' development, but if it's broken.... .
But maybe now I have the RPI working, I could go back to ESP32 - I now know that it works better at <50kbits, etc. Maybe even make a generic Tasmota driver for SPI which could be driven over IP? I see no reason why the ESP SPI should NOT work, and successful read is reported using ESP8266 (code here: https://mitxela.com/forum/topic/beken-bk3231/2) But SPI is only NEEDED for recovery (and maybe detailed initial dev), so RPI solution is probably ok for now. Most people can use the Uart flash.
Note that this SPI SHOULD work with quite a few Beken chips - e.g. BK3432 has no Uart upload in it's bootloader, so SPI/JTAG is the only route.
Now we understand the SPI portion, with a little effort it would be possible to directly reproduce the Beken SPI hardware hid device (all the commands are in the repo) using a USB equipped chip. Not done it for a long time, and all the ones I had were 5v.
If someone here had a JLINK adaptor, it would be very interesting to see if JTAG can be brought up. Because I just rebuilt my RPI3b, I *should* now be able to build and run openocd with the RPI JTAG driver and try it - but maybe later, now I'd like to do some firmware .
p.s. since we are now running firmware with wifi, we could easily add something to read/write flash - e.g. to read out the bootloader for comparison with other bootloaders found. Far easier than wiring up SPI...
I will add a simple command line interface today, so we can, for example, call "tuya_hal_flash_read 0x1e1000 0x10" remotely and see results on HTML page. Simple commands will be also useful for the scripting in the future (I've already wrote simple scripting interpreters in the past so it should not be a problem)
I've found another WB3S device:
This time with MCU... TuyaMCU UART protocol, maybe?
Code: c
Log in, to see the code
EDIT: i've found my SSID few bytes after decimal offset 1974266:
Here is how they read it:
TLV header is earlier:
but the code for setting was indeed not included in the build. Still, I have modified it and added 64 bytes field for storing pins configuration, let's see if it runs.
Btw: @btsimonh if you want to do OTA upgrade, you should first download bytecode to specific OTA area and then allow old update mechanism to write it to user area, I think
. Maybe attach the output .bin file here?
