[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:
url=https://obrazki.elektroda.pl/2809551800_1749377086.jpg][/url]

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