[BK7231N] Teardown and flashing of Atorch GR2P-WS: DIN rail device with graphic screen

divadiow wrote:

ah ok. interesting. dunno then really. maybe something new in the main 3.1.17 fw that means MCU also requires different firmware? I'm going to interrogate my CH573 soon in Atorch S1

Could be, I had also thought about that possibility...

Could I flash 3.1.17 in the older one with 2.1.17 and see if it prompts for an MCF FW upgrade, or will this break something?

morgan_flint wrote:

Could I flash 3.1.17 in the older one with 2.1.17 and see if it prompts for an MCF FW upgrade, or will this break something?

could try? If you don't go through with any update, then maybe it'll be fine?

or, I have already tested - I flashed your new device backup to BK7231N and used same pid in Tuya MCU debug assistant. I specified MCU version 0.0.1 -> offers update 1.0.3 still. Then I stepped up a version at a time 1.0.3->1.0.7 but no updates were offered at any level.

divadiow wrote:

I don't suppose you have the full boot log with what the real MCU sends as its ID, assuming that's visible in the log?

In case it can give more information, here's the log

confirms the pid I guess - sq1ahfxhgove4kgo

Spent hours trying to get my only CH573F into UART ISP mode to no avail. This is from the Atorch S1-B. managed to trace a lot though with decent confidence it's right


I even took off the BL0942 to clear any potential interference when pulling PB4 low at power-on. This was to be my tool of choice https://github.com/ch32-rs/wchisp



USB- and USB+ showed no signs of USB ISP device detection either however you pulled PB4/PB23.

Device would always boot and do it's normal beep and Atorch LCD display boot checks. PB23 RST didn't seem to reset anything either, so, dunno.

>>21568294
Thank you for your tests!

I've also attempted, but without too much fortune...

My approach was to use the USB port with the instructions here, downloading the drivers and programs also there.

I connected a USB port, according to the pinout I had described in this post:



Plugging in the USB to the PC running WICHISPStudio, and with BOOT (pin 17) grounded, the USB device was detected and recognized by the program:


Unfortunately, there's no option in the program to backup the flash; only an option to read the EEPROM:


(Attached the 32 KB file, which is almost full of FF, except for a few bytes)

Could this procedure be useful to flash the firmware in your GitHub repository?

I'm not sure if it's worth risking the device, anyway (it'd be more for the fun of experimenting than for the possible benefits 😂)

It seems like CH573 has memory read-out protection by default and, although this video explains a bypass to it, I'm not sure if I would be able to replicate it, nor if I would get something useful from that. I read something about FW encryption at the end of this page, but I don't fully understand its consequences.

Thanks again for helping me learn something about these things.

blinded by my own adventure! thanks for pointing out your previous post. I'd not fixated enough on USB mode and the presence and significance of PB22. I had come across that video too on Youtube

I have now managed to get the USB device to show, albeit for a limited period of time, before the CH573F boots into normal mode again.




I see we both have bootloader version 2.90.

With WCHISPStudio open the USB seems to stay open for longer, long enough to change the driver with Zadig to the WinUSB driver needed for wchisp to operate in USB mode

so then with wchisp.exe info I get



and I can dump the eeprom too to file




next, I'll see if I can wrap my head around that post and what it means for dumping full flash https://github.com/frank-zago/isp55e0?tab=readme-ov-file#note-on-the-firmware-encryption

morgan_flint wrote:

Could this procedure be useful to flash the firmware in your GitHub repository?

The Atorch_GR2P-WS_MCU_WCH_CH573F_1.0.3.bin OTA bin?

Added after 2 [hours] 37 [minutes]:

the dump flash options in https://github.com/frank-zago/isp55e0 and https://github.com/MarsTechHAN/ch552tool just read eeprom (for me)

Added after 26 [minutes]:



https://github.com/frank-zago/isp55e0/blob/master/protocol.txt

so yes, my readout is disallowed, as expected, and it looks like flashing would fail anyway. Also, you notice in that video that atc1441 has to write a program to read out the flash over uart, which is initially flashed to the CH573F, overwriting existing data. His uart output happens to include the OTA2 bank firmware. This method is the 'bypass' that was reported to WCH. His device had BL v2.80 - I wonder if 2.90 is patched for this anyway. If 2.90 isn't patched then I guess we'd have to - locate that program, compile and upload it (assuming CFG_ROM_READ is 0, flashing will fail is incorrect), potentially sacrificing a device to see if untouched OTA2 exists in firmware.

divadiow wrote:

and I can dump the eeprom too to file

Just for curiosity, I compared yours with mine, and although they belong to different devices, they seem to have a similar structure with an offset of 100h (different contents, of course):



The programmer at Atorch is reusing a lot of code, I suppose.

divadiow wrote:

If 2.90 isn't patched then I guess we'd have to - locate that program, compile and upload it (assuming CFG_ROM_READ is 0, flashing will fail is incorrect), potentially sacrificing a device to see if untouched OTA2 exists in firmware.

I'm not sure it's worth the sacrifice 😂

I'm planning on buying one of these to experiment with

morgan_flint wrote:

I'm not sure it's worth the sacrifice 😂

no indeed.

morgan_flint wrote:

I'm planning on buying [https://www.aliexpress.com/item/1005006806579557.html]one of these[/url] to experiment with

me too!

morgan_flint wrote:

With that in mind, and also wanting to inspect the HW differences with GR2PWS, I have ordered (and am waiting for its arrival) a GR2PWSL (with external leakage current transformer). In the advertisement, some pictures of the device's screen are different from my devices, or even don't exist in them, but are similar to those in AT4P advertisements. So I'm also curious to check the FW version in this new acquisition. In one of the ad's screenshots it says "BengFang Sys Settings 2.0.1":

My new GR2PWS version, GR2PWSL, finally arrived!
As could be foreseen from the photos in the advertisement I posted in the referred post, it's a different version than the previous GR2PWS devices shown in this thread, not only beacause this one has an external current transformer (and tha associated components in the PCB), but also because the MCU FW is different (more options in the device's screen), and also hardware differences (another MCU). On the other hand, and from the MCU - WiFi Module communication perspective, no important changes have been made, as we have the same dpIDs with only a slight difference (more on this later).

To start with, let's see the update screen in the Tuya App:


Compared to those of my older devices, posted in the referred post:


So, new versions for both the Main module and the MCU module.

Now, the HW differences:


The layout has some differences with the previous one, the most eye-catching being the MCU and the location of its programming port. Let's see some details:


The MCU is very different (32 pins instead of 28), but the main components (SMPS, metering, relay driver) are very similar to the previous version. Of course, the shunt resistor (510 ohm) for the leakage current measuring, and also the equivalents of the other two missing in the other ones, are installed in this one:


The other two components are a series resistor (also around 500 ohms) and a capacitor to GND, as I suspected in the previous post:

Quote:

The missing components circled in the other photo are probably a capacitor to GND and a resistor between pad 2 and pin 28 of the MCU, which would be configured as an analog input for residual current measurement:

I could check that the residual current transformer has a relationship of 1:1000:


So I guess just adding these 4 components (current transformer, shunt resistor, series resistor, and capacitor), it would be possible to measure leakage current in the older devices, as the FW seemed to be prepared for it also in them. Alternatively, the pin where the resistance is connected can be used to measure a voltage between 0 and 102 mV (would be interpreted by the FW as 0 - 200 mA, approximately).

Now, let's see the differences in the FW from the device's screen point of view. These are very similar, maybe a slight difference in colours:


The differences start with the graphics:


And continue in the settings menu, and a new standby screen:

I'll stop here by now because I have to leave, but still have to add more info later...

It's curious, but there isn't an entry in the screen menus to set the residual current limit and enable protection; this is done in the Tuya App (also present in the model without the necessary HW):


And this is the info on the screen and the App after a leakage:


To conclude this long post, this is the "Things Data Model" from Tuya Developer's web, extracted according to my tutorial:


Translation of Chinese words is a pending job for @ElektrodaBot... I asked him to do another translation for me here, but he seems to be ignoring that thread 😂😂

On comparing this JSON with the one for the previous models, apart from the ModelID, I've only found one significant difference, that is the scale in dpID 101 (electricity price), which changed from 2 to 3. ModelId and ProductId have changed:



@divadiow: Still pending to extract the backup of the WiFi module's FW, I'll try to do it soon

>>21573408
@ElektrodaBot
Could you replace the Chinese words in the following JSON with their English equivalents?

ElektrodaBot wrote:

If you need the tail end of the file (abilityId 136 – 142) translated as well, just let me know and I’ll complete it.

@ElektrodaBot
Yes, please

>>21569371
yay

I received similar GR2PWS like @morgan_flint.
Some notes:

1. I tried to flash OpenBK7231N_QIO_1.18.135.bin via BK7231GUIFlashTool. Flash after desoldering the module succeeded but OpenBK did not start up properly.
No AP, very low energy consumption (my cheap power supply show around 0.01A). I tried multiple times; flash, restore, cleaning RF part.
Finally I flashed bootloader from GR2PWS_Reset_BK7231N_QIO_2024-23-6-20-54-08.bin to my cb2s (WiFI module).
I used bk7231tools, log from that operation:


After that, OpenBK started up correctly.

2. tuyaMcu BaudRate is 115200.

Hello, perhaps my experience and the information I provide will be useful.
Last year, I had an unsuccessful update on my GR2PW device via tuya-update due to weak Wi-Fi in the workshop and premature shutdown of the device.

Added after 1 [minutes]:

This is what the page looked like.


Added after 1 [minutes]:

The device itself displayed the following on its built-in screen


Added after 2 [minutes]:

After changing locations to one with a good signal, I received the following information from Tuya


Added after 4 [minutes]:

Looking for a solution to this problem , I finally found this thread and tried flashing the update posted above.
The result is a constant reboot after the logo sound and the loading progress bar

Added after 3 [minutes]:

Of course, this is not my last attempt to restore the device.
I would appreciate any advice on how you store tuya binaries.
Does anyone have binaries for GR2PW?

I'm not sure I can help much (probably, @divadiow is a better candidate), but just to be sure to understand your problem:

First doubt, I understand your device is similar to my first two GR2PWS (MCU CH573), as the third one I bought, GR2PWSL, has a different MCU, which FW hasn't been published here.
Second doubt:

seregagnelicky wrote:

Looking for a solution to this problem , I finally found this thread and tried flashing the update posted above.
The result is a constant reboot after the logo sound and the loading progress bar

Which binary are you referring to? Which post?

Third question:

seregagnelicky wrote:

Looking for a solution to this problem , I finally found this thread and tried flashing the update posted above.

Are you flashing it via USB?

As you can see in the previous posts, we tried downloading the Tuya MCU's FW via USB, but there's an encryption issue...

@divadiow posted here he had bought a device for experimenting with FW flashing; perhaps he has made some progress in the investigations.

morgan_flint wrote:

@divadiow posted here he had bought a device for experimenting with FW flashing; perhaps he has made some progress in the investigations.

alas, no. they went back in their packet and havent come out since :/

>>21617488
I will try to explain in more detail and clarify the points that I took for granted.
So, working with this MCU does not allow you to read the firmware dump only from EEPROM or as in the WCH_ISP_Tool (DataFlash) program, so the only hope in this case is tuya-update, and I am grateful to @divadiow for the opportunity to even try this.
That is, the firmware file was used
Atorch_GR2P-WS_MCU_1.0.3.bin
Physically, 12. 13 MCU pins and GND were connected to the PC, as well as three USB wires: D+, USB D-, and GND. The power supply was connected separately.
The program downloaded and checked the firmware.
You know the result.
I understand that there may be flaws in my logic and that I may have done something wrong. If so, please guide me.
Now I am inclined to think that the firmware I uploaded is from another device, which is why I am getting a cyclic reboot.

Added after 42 [minutes]:




Added after 5 [minutes]:

I also forgot to write an important point pin 17 (boot) must be connected to GND since the MCU will periodically turn off the USB I add a screenshot when the USB is activated

Could it be that it has something to do with the offset (memory location) where the FW is written?

I'm leaning towards buying a ch-link and trying to dump the dump from the working device, but this is a last resort as fw may be protected
in attaching the eeprom from the working device

just re-reading and seeing if I understand what's happened. Also trying to remember what we discovered even though it was only two months ago :o

See this bit here

divadiow wrote:

so then with wchisp.exe info I get

then it shows this in my device info



then further down



did you do a wchisp.exe info on your chip?

Added after 5 [minutes]:

If it's locked then I don't know what the options are, if anything.
There is mention of doing OTA updates to TuyaMCU from within OpenBeken but I don't think development on it went far, and even if that did work I guess your CH573F would need to be in a functioning enough state to accept an update