Hung in ambztool for RTL8710BX

[kexis0]

I am trying to make a dump of a RTL8710BX from the Govee Lynx Dream String Lights (H7021) to make a backup before putting esphome on the chip. I am able to get into boot mode but end up getting stuck on 'resp += self.read()' in ambztool.py.

LOG:

$ sudo ltchiptool -vvv flash read ambz govee-h7021-stock.bin -d /dev/ttyUSB1                                          
D: Found PlatformIO Package (v1.6.0) - /root/.platformio/platforms/libretiny
D: Found Local data snapshot (v1.5.1) - /home/brian/projects/govee/h7021/venv/lib/python3.12/site-packages/ltchiptool
I: Connecting to 'Realtek AmebaZ' on /dev/ttyUSB1 @ 1500000
D: Linking: stage 0                                         
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
D: Linking: stage 1                                         
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
D: Linking: stage 2                                         
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
V: -- UART: Port baudrate set to 1500000
D: Linking: stage 3                                         
I: Connect UART2 of the Realtek chip to the USB-TTL adapter: 
I:                                                          
I:     --------+        +---------------------
I:          PC |        | RTL8710B            
I:     --------+        +---------------------
I:          RX | ------ | TX2 (Log_TX / PA30)                                                                            
I:          TX | ------ | RX2 (Log_RX / PA29)               
I:             |        |                                                                                                
I:         GND | ------ | GND                               
I:     --------+        +---------------------                                                                           
I:                                                                                                                       
I: Using a good, stable 3.3V power supply is crucial. Most flashing issues
I: are caused by either voltage drops during intensive flash operations,
I: or bad/loose wires.                                      
I:                                                          
I: The UART adapter's 3.3V power regulator is usually not enough. Instead,
I: a regulated bench power supply, or a linear 1117-type regulator is recommended.
I:                                                          
I: In order to flash the chip, you need to enable download mode.
I: This is done by pulling CEN to GND briefly, while still keeping the TX2 pin
I: connected to GND.                                        
I:                                                          
I: Do this, in order:                                       
I:  - connect CEN to GND                                    
I:  - connect TX2 to GND                                    
I:  - release CEN from GND                                  
I:  - release TX2 from GND                                                                                               
V: -- UART: Port baudrate set to 1500000                                                                                 
V: -- UART: Port baudrate set to 1500000                                                                                 
V: -- UART: Port baudrate set to 1500000      
D: XMODEM: transmitting to 0x10002000
V: push_timeout(1.0)
D: Begin start sequence, packet_size=1024
D: Begin start sequence, packet_size=1024
D: standard checksum requested (NAK).
D: standard checksum requested (NAK).
D: send: block 1
D: send: block 1
D: send: at EOF
D: send: at EOF
D: sending EOT, awaiting ACK
D: sending EOT, awaiting ACK
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
V: pop_timeout()
V: push_timeout(0.1)

Here it will hang indefinitely without timing out on line:

ltchiptool/ltchiptool/soc/ambz/util/ambztool.py

Line 446 in 2868532

resp += self.read()

I started to debug it and found that it will loop 2 times before getting stuck. The value of resp is b'\x18\rxmodem_log_open \n\r\rclose xModem Transfer ...\r\n\r'.

Any idea if I am doing something wrong? It seems like xmodem is being closed but I'm not too familiar with what normally occurs.

[kexis0]

Okay, I think I figured it out. I made the timeout shorter and it worked for me. I am not entirely sure why this works, but I get the same .bin file each time.

diff --git a/./venv2/lib/python3.12/site-packages/ltchiptool/soc/ambz/util/ambztool.py b/./venv/lib/python3.12/site-packages/ltchiptool/soc/ambz/util/ambztool.py
index dc88e59..de818c2 100644
--- a/./venv2/lib/python3.12/site-packages/ltchiptool/soc/ambz/util/ambztool.py
+++ b/./venv/lib/python3.12/site-packages/ltchiptool/soc/ambz/util/ambztool.py
@@ -438,7 +438,7 @@ class AmbZTool(SerialToolBase):
         # send RAM code, exit download mode (changes baudrate to 115200)
         self.ram_boot(code=code, callback=callback, keep_baudrate=True)
 
-        self.push_timeout(0.1)
+        self.push_timeout(0.01)
         resp = b""
         end = time() + timeout
         while time() < end:

[kexis0]

I was wrong. That did not do what I expected. I get the .bin file but binwalk failed and a hexdump shows:

binwalk govee-h7021-stock.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

hexdump -C govee-h7021-stock.bin 
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00200000

[kexis0]

Any thoughts on what else I can try?

[kuba2k2]

Sadly, no. You could try using an old version (before 4.8.0, I think) which had an old implementation of the RTL flashing tool.

[Gitlegov]

Sadly, no. You could try using an old version (before 4.8.0, I think) which had an old implementation of the RTL flashing tool.

Having also this issue with current version 4.11.1 during "checking OTA index".
One out of three boards (McuBoard: T102_V1.1 / MCU: RTL8710BX / target device) passed this step and successfully flashed.
Version 4.7.0 worked like a charm with the other two devices without changing anything on the hardware setup

similar to this issue