Set the MCU to UART boot mode (pull TX pin low during boot)

[Belaial]

Hi

Not an issue with the project or the code but asking here anyway in case someone else wonders and can look up this ticket.

"Set the MCU to UART boot mode (pull TX pin low during boot)"

I am not familiar what it means to pull a pin low, I am using a USB to serial adapter and can read the boot process just fine with a speed of 115200, however to enter into "Set the MCU to UART boot mode" I need to pull the TX pin low, could someone explain how that is done?

Maybe it can't be performed with a regular cheap USB to Serial adapter?

[hn]

Hi @Belaial , thanks for asking. You just have to connect the TX pin to the GND pin during boot with a small piece of wire. Remove the wire some seconds after you powered on the board.

[Belaial]

Ah ok, that was my guess (and a friend I asked) but wanted to be 100% sure before I tried! Will try and re-flash my stick later today! Thanks for the reply.

[Belaial]

I am not sure I am able to get the stick into the correct mode, in the guide there is the following when the stick is in the "xmodem mode"

ROM:[V0.1] FLASHRATE:4 UARTIMG_Download 2 Open xModem Transfer on Log UART...

I am not able to see this after connecting TX to GND for a few second during boot and then removing the wire (wire not connected in the picture but I connect it to GND before boot and then remove it a few seconds later)

When I have done this and then sudo screen /dev/ttyUSB0 115200 to see what is going on all I see is a continuous spam of this

Am I doing something wrong trying to get the stick into "xmodem mode" maybe? Or am I using the wrong rate (115200) when looking what is going on?

If I just boot the stick normally I see the boot log just fine with 115200 so the serial adapter and wires are OK at least.

[hn]

Hm, strange, never experienced this. It looks like you do everything right.

Try using a small resistor (200 Ohm ... 1kOhm) instead of the wire.

What stock stick firmware do you have? Maybe they changed (protected) something.

[Belaial]

I will try the resistor instead of the wire later on today, need to get the resistor, don't have that at home.

Not sure what version it's running, hopefully this can tell

ROM:[V0.1] FLASHRATE:4 BOOT TYPE:0 XTAL:40000000 IMG1 DATA[1128:10002000] IMG1 ENTRY[800053d:100021ef] IMG1 ENTER CHIPID[000000ff] read_mode idx:2, flash_speed idx:2 calibration_result:[1:19:13][3:15] calibration_result:[2:21:11][1:15] calibration_result:[3:0:0][ff:ff] calibration_ok:[2:21:11] FLASH CALIB[NEW OK] OTA2 ADDR[8100000] OTAx SELE[ffffffff] OTA1 USE IMG2 DATA[0x800f300:36:0x10005000] IMG2 SIGN[RTKWin(10005008)] IMG2 ENTRY[0x10005000:0x800b239] BOOT_FLASH_RDP RDP enable RDP bin decryption Failed! checksum_ipsec = 0xa3680b78, checksum_rdp_flash = 0xb26d9300 2ndboot image start

Press key 'w' to 2ndboot cli menu in 100ms. 122: ota crc cal:0x7a1a param:0xffff

17: ota upg_flag:0xffffcount:0 crc;0xffff

30: No OTA upgrade.

os image start System_Init1 System_Init2 interface 0 is initialized interface 1 is initialized

Initializing WIFI ... LDO Mode, BD_Info: 0

LDO Mode, BD_Info: 0

WIFI initialized

hal_wlan_init(75), Available heap 0x88792

============free heap size =84128========== Read parameter success. ------------Ali_V00010130_SN5A122517BC30963D------------

---

The collector.total_working_time :196054 The collector_record.startup_cnt :277 The collector_record.restart_cnt :4 The collector_record.restart_reason :25 The ginlong_flag.inverter_update_fail:0 The http_info.download_record :0

---

1 ssid xxxxxxxx channel 64 rssi -77 2 ssid channel 64 rssi -78 3 ssid xxxxxxxxxxxxxx channel 64 rssi -78 4 ssid xxxxxxxx channel 64 rssi -95

1 ssid xxxxxxxx channel 64 rssi -78 2 ssid channel 64 rssi -79 3 ssid xxxxxxxx channel 64 rssi -79 4 ssid channel 64 rssi -89 5 ssid xxxxxxxx channel 64 rssi -91

LwIP_DHCP: dhcp stop. Deinitializing WIFI ... WIFI deinitialized Initializing WIFI ... LDO Mode, BD_Info: 0

LDO Mode, BD_Info: 0

WIFI initialized

LwIP_DHCP: dhcp stop. Deinitializing WIFI ... WIFI deinitialized Initializing WIFI ... LDO Mode, BD_Info: 0

LDO Mode, BD_Info: 0

WIFI initialized ROM:[V0.1] FLASHRATE:4 BOOT TYPE:0 XTAL:40000000 IMG1 DATA[1128:10002000] IMG1 ENTRY[800053d:100021ef] IMG1 ENTER CHIPID[000000ff] read_mode idx:2, flash_speed idx:2 calibration_result:[1:19:13][3:15] calibration_result:[2:21:11][1:15] calibration_result:[3:1:1][1:1] calibration_ok:[2:21:11] FLASH CALIB[NEW OK] OTA2 ADDR[8100000] OTAx SELE[ffffffff] OTA1 USE

[hn]

You have a newer firmware v10130 (line: "AliV00010130"). They might have disabled uart boot mode, but somehow I would be surprised if they had. It's worth going on.

[Belaial]

Ok, stick was purchased in October 2022 (in Finland if that matters) Let me know if you need more info regarding the stick!

I will try the resistor later today and see what happens, I have nothing to loose since I won't use the stick with stock firmware anyway (running a pi now but wanna try this project also).

Either we get it to accept custom firmware or the stick dies, whatever comes first :+1:

[Belaial]

Ok, so I have now tested with 180 Ohm, 470 Ohm and 1kOhm, results are interesting and the same for all resistors

I now get to see the ROM:[V0.1] FLASHRATE:4 UARTIMG_Download 2 Open xModem Transfer on Log UART...

However the last line Open xModem Transfer on Log UART... is after like 2 seconds overwritten with all those ???????????????????

If I try to read the stock firmware I get this

If this is due to not having python2 implemented correctly I don't know, I am still on the same computer as explained in ticket https://github.com/hn/ginlong-solis/issues/10 I was however able to get pyserial2.7 installed, not sure if something else is broken with python2 tho.

EDIT

Forgot to mention.... when using the plain old wire to connect GDN / TX I do not get to even see the ROM:[V0.1] FLASHRATE:4 UARTIMG_Download 2 Open xModem Transfer on Log UART... part, if I use the wire the ???????????? just start spamming instantly when I disconnect the wire.

[hn]

Close screen to have the serial port unblocked. And then try rtltool regardless of the '?'.

And maybe try a 10kOhm resistor? It looks like theres something wierd with your serial adapter and/or cabling, the stick seems to be ok (and not UART-protected).

[Belaial]

I do close screen in between so that the serial port is not in use, I only check it to see what is going on, tested a few times not to not use screen at all but results are the same, failed to connect device on /dev/ttyUSB0

10kOhm seems to be to much, tried 10+ times, always boots into regular mode, will try something lower and see what happens.

[Belaial]

10kOhm - to much 7.5kOhm - to much 6.8kOhm - to much

3.9kOhm - Ok (however same ???????? spam) 3kOhm - Ok (however same ???????? spam) 2.2kOhm - Ok (however same ???????? spam) 1kOhm - Ok (however same ???????? spam) 470Ohm - Ok (however same ???????? spam) 180Ohm - Ok (however same ???????? spam)

EDIT

Regarding serial adapter / cabling

Very simple adapter, cables like 10 cm long, soldered pins in both ends so should not be bad contacting at least.

EDIT2

Tested to hold "w" at boot and that worked flawlessly, got into that "2ndboot#" instantly.

[Belaial]

It looks like theres something wierd with your serial adapter and/or cabling, the stick seems to be ok (and not UART-protected).

Any tips what adapter I should get? Have tried all I can think of for now at least without luck. Next step is to fix another Linux machine that does not have mixed Python 2/3 in case that could be the issue.

I will be traveling for work coming days so won't have access to this stuff again before Friday 16 of June, weekend when I get home so might take until Sunday 18 of June before I can test any idea's if someone comes to think of something.

[hn]

Connect VCC to 5V, this is what I use (RX/TX are jumpered to 3v3 level, though).

[Belaial]

Ok so I have made some progress now, the issue is neither with the USB-serial converter or the cables, it seems to be a issue with my mixed Python 2/3 environment in Fedora.

I have booted a old Linux Mint 18 and there I can get the status Flash Status value 0x40 and also start dumping the firmware.

However the dumping is so slow that the stick seems to reboot after some time, I have not timed it (maybe 10 minutes or so) but I managed at best to dump 750K before it fails and then I see the LEDs on the stick starts flashing like it does during a normal boot.

Did you ever run into the same issue @hn or could you dump the stick faster?

EDIT

Tested now on a second computer, same deal, after like 10 minutes stick just reboots and the dump fails. Also verified with sudo screen /dev/ttyUSB0 115200 afterwards that it indeed just boots normally.

I somehow need to speed up the process (or make it not reboot somehow) otherwise there is not enough time it seems.

EDIT2

I timed it now, 15 minutes exactly, then it just reboots.

EDIT3

I now tried to leave the 470Ohm resistor connected between TX /GND, same deal, 15 minutes and it just reboots, if this is a feature of the new Ali_V00010130_ I am not sure, all I know is that there is not enough time to dump the firmware, if I can speed it up somehow I am not sure of, hopefully there is some trick to do that.

[hn]

Dumping the firmware takes some time, but I would say it's more like 2-4 minutes, but don't remember exactly.

You can try the alternative tools @hcouplet mentioned here: https://github.com/hn/ginlong-solis/issues/7#issuecomment-1561865512

[hn]

I got access to another S3 WiFi stick, this time with firmware 10154. Dumping still works flawlessly (with this higher firmware version than yours), it took a good 3 minutes for the full 8MB flash. I shorted GND and TX with a paper clip, so using a resistor is irrelevant.

[Belaial]

Dumping the firmware takes some time, but I would say it's more like 2-4 minutes, but don't remember exactly.

You can try the alternative tools @hcouplet mentioned here: #7 (comment)

I will look into this, however I need some account to download stuff from RealMCU and not getting their download to work at the moment.

[Belaial]

I got access to another S3 WiFi stick, this time with firmware 10154. Dumping still works flawlessly (with this higher firmware version than yours), it took a good 3 minutes for the full 8MB flash. I shorted GND and TX with a paper clip, so using a resistor is irrelevant.

Do you have a name / model on that USB to serial adapter? Was thinking I could get the same one to see if that helps out.

EDIT

Never mind, found it on eBay, just need to find a seller with good shipping to my area.

[Belaial]

I will close this ticket since you can dump this on even newer firmware, I will report back if I ever solve this and manages to dump and re-flash my stick. The issue once again is not with the project but seems to be all kinds for weird issues on my end.

Many thanks for helping out and replying to all my questions.

[hn]

I have a bunch of cheap serial adapters from the last 10 years or so, all of them within reach work. I have really no idea what's wrong with your setup. Serial adapters aren't rocket science :) I think it may have to do with the 5V VCC pin not having enough power to reliably supply the stick, but that's just a rough guess.

[Belaial]

I read up some more during the weekend and even tho I closed this ticket already I will post what I found. My USB-serial adapter is based on CP2102 chip, what I could find it supports a maximum baud rate of 921600 according to https://www.sparkfun.com/datasheets/IC/cp2102.pdf

I noticed the following in the code for the rtltool.py RTL_ROM_BAUD = 1500000

Therefore my best guess now is that this USB-serial adapter i have is to slow to dump the firmware before the stick automatically reboots after 15 minutes.

I have ordered a new USB-serial adapter, just like the one in your pictures, will take a few weeks for it to arrive (slow shipping from eBay seller), I will let you know how it goes once I get it.

EDIT

Did not notice your reply regarding low power on 5V VCC, I guess it could be possible but I have had the stick booted normally for hours, and that seems to work just fine, it just stands there looking for it's SSID I configured when I tested the stick out towards the Solis inverter, therefore I think that power should be fine, can't guarantee it but that is my rough guess.

The "only issue" now is the automatic reboot that only seem to exist in the "download mode", timed it a few times and it's always 15 minutes, at least on my stick, so again my only guess is that my serial adapter is to slow to complete the dump in time, I guess it also would be to slow to flash the stick.

And you are correct that serial adapters ain't rocket science :) But in some weeks we might know what science is behind my issues.... maybe they are related to speed / to cheap adapter.

[hn]

If my firmware dump took a good 3 minutes, that's roughly 45000 bytes per second for 8MB, which is about 460800 baud.

The currently connected adapter shown in the picture is a Future Technology Devices International, Ltd FT232 Serial (UART) IC, with which dumping works.

[Belaial]

Ok,

I managed to dump ~0,75MB in ~15 minutes so that is quite slow compared to your results, will be interesting to see if another adapter helps out, unfortunately I have no other adapter to test at home so will just have to wait for the new one to arrive which will take some time unfortunately but I will update once I know.

I also tested 2 different computers just to be sure, only thing that followed along was the adapter.... so my hope is that is where the issues is.

I ordered these ones

https://www.ebay.com/itm/202647978588 https://www.ebay.com/itm/381374421597

I know they are based on the same chip but once I order something I usually take more then I need since the shipping is so slow anyway :)

[kuba2k2]

Hi @Belaial the "continuous spam" you're getting on serial port is expected and valid - this is the chip saying "hey, I'm in xmodem mode". You should be able to run the dumping/flashing in this mode.

When shorting TX to GND with a wire, you're blocking the TX output from the chip (it can't send anything since the wire is "stronger" than the chip), so not seeing the xmodem boot message is also completely normal.

However, I can't say exactly why is it failing for you. Using a good (real) FT232RL adapter is the best choice, as the BootROM initializes on 1.5Mbit baudrate, which is quite high for cheap adapters. I think you can set a lower baudrate in rtltool (it will still initialize on high baud, but will lower it for the actual data transfer), which should give you more luck.

[Belaial]

Hi @kuba2k2

Figured it should be normal behavior to see the "continuous spam", have worked a lot with serial connections on network equipment so now and then I do see things like this.

Regarding changing the baud rate in rtltool I tried that (to the best of my knowledge at least) but it did not have any impact as far as I could tell, a real FT232RL is indeed the best choice, I have ordered a few and are still waiting for them, takes quite a few weeks for them to arrive, once they do I will test again and update this ticket how it goes!

[Belaial]

Hello again!

Today I got my new serial adapters, just like the one in your picture @hn and I can now HAPPILY inform you that I can now dump the firmware in 1 minute 5 seconds, I even tried 3 times in a row since it felt soooooo good to finally have the solution to this problem! Worked flawlessly every single time!! :)

I might take the time to re-flash the stick tonight but I will probably not do it before tomorrow or this weekend.

So we can now for sure say that a serial adapter based on the CP2102 chip is not enough to preform these actions, you need something more serious like the FT232RL.

[kuba2k2]

Hi @hn, I've just written a brand new flashing tool for RTL8710 - without relying on rtltool.py anymore. It seems to be stable now, and supports read-retry and hash checking too. The GUI/CLI is obviously the same (ltchiptool), but it's different under-the-hood.

You can get it here - it's not released yet: https://github.com/libretiny-eu/ltchiptool/tree/feature/flasher-update

[not sure where should I put it, so I put it here.]

EDIT: Oh, and it can also auto-detect flash size, so it allows flashing over 2 MiB now. I'd appreciate someone with access to an RTL8710 testing it.

[hn]

@kuba2k2 Hi, nice to hear from you :) I did a quick test but something does not work work [maybe I did something wrong]:

cd /tmp/lt-git-new
git clone https://github.com/libretiny-eu/ltchiptool.git
git checkout feature/flasher-update
pip3 install /tmp/lt-git-new/ltchiptool/ -t /tmp/lt-test

$ PYTHONPATH=/tmp/lt-test /tmp/lt-test/bin/ltchiptool  -V
ltchiptool v4.7.0
$ PYTHONPATH=/tmp/lt-test /tmp/lt-test/bin/ltchiptool flash read rtl8710b /tmp/dummy -l 0x800000
I: Available COM ports:
I: |-- ttyUSB0 - FT232R USB UART - FT232R USB UART - FTDI (0403/6001)
I: |   |-- Selecting this port. To override, use -d/--device
I: |-- ttyAMA0 - ttyAMA0
I: Connecting to 'Realtek AmebaZ' on /dev/ttyUSB0 @ 1500000
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
E: RuntimeError: Response unreadable: b'\x0c5\xe1\xb5\xbd\x91\x95\xb5}\xb1\xbd\x9d}\xbd\xc1\x95\xb9\x81Rj\xd44\x8b\xebkW\x16$\xafS\x8bVV\x0b\x12\x95\xae,k\x97V\x96.$\xc9\xc9\xa9H\xa8\xe8h@\x17UARTIMG_Download 2\n\r\rOpen xModem Transfer on Log UART...\r'
E: |-- File "/tmp/lt-test/ltchiptool/soc/ambz/util/ambztool.py", line 453, in ram_boot_read

With '-s', the serial data looks like this (just an excerpt):

S: -> RX: b'\x15'
S: -> RX: b'\x15'
S: -> RX: b'\x15'
S: -> RX: b'\x15'
S: <- TX: '!!'
S: <- TX: b'\x07'
S: -> RX: b'\x06'
S: <- TX: 01 01 FE 00 20 00 10 19  20 00 10 9B 21 00 10 EF  .... ... ...!...
S: <- TX: 21 00 10 F5 20 00 10 EF  21 00 10 41 05 00 08 03  !... ...!..A....
S: <- TX: 48 F8 21 04 4A 07 23 02  4C A0 47 06 E0 00 00 AE  H.!.J.#.L.G.....
S: <- TX: 26 00 00 65 6D 00 00 00  30 00 10 9F 20 03 21 02  &..em...0... .!.
S: <- TX: 4A 01 4B 98 47 03 E0 65  74 00 00 01 30 00 10 03  J.K.G..et...0...
S: <- TX: 48 04 49 01 4B 98 47 06  E0 00 00 49 EC 00 00 00  H.I.K.G....I....
S: <- TX: 30 00 10 04 00 00 00 02  20 01 4B 98 47 00 00 01  0....... .K.G...
S: <- TX: 09 00 00 FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
S: <- TX: FF FF FF FF FF FF FF 91                           ........
S: -> RX: b'\x06'
S: <- TX: b'\x04'
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
S: -> RX: 0C 35 E1 B5 BD 91 95                              .5.....
S: -> RX: B5 7D B1 BD 9D 7D BD C1  95 B9 81 52 6A D4 34 8B  .}...}.....Rj.4.
S: -> RX: EB 6B 57 16 24 AF 53 8B  56 56 0B 12 95 AE 2C 6B  .kW.$.S.VV....,k
S: -> RX: 97 56 96 2E 24 C9 C9 A9  48 A8 E8 68 40 17 55 41  .V..$...H..h@.UA
S: -> RX: 52 54 49 4D 47 5F 44 6F  77 6E 6C 6F 61 64 20 32  RTIMG_Download 2
S: -> RX: 0A 0D 0D 4F 70 65 6E 20  78 4D 6F 64 65 6D 20 54  ...Open xModem T
S: -> RX: 72 61 6E 73 66 65 72 20  6F 6E 20 4C 6F 67 20 55  ransfer on Log U
S: -> RX: 41 52 54 2E 2E 2E 0D                              ART....
E: RuntimeError: Response unreadable: b'\x0c5\xe1\xb5\xbd\x91\x95\xb5}\xb1\xbd\x9d}\xbd\xc1\x95\x

Same for 'flash write'!

[kuba2k2]

Hmm, the response seems to be identical in both of your test runs (which would be odd if the garbage data was caused by incorrect baudrate). Can you try setting baudrate to 115200 manually (-b I believe)? Also, if you run it with -vv it will spit out more info about changing port baudrates etc. The program tries to read the flash ID by executing code in RAM of the Realtek chip. It expects to see a few log messages right before the flash ID comes through. It seems that the flash ID shows up though - it might be E8 68 40 17, which indicates a size of 8 MiB. The chip ID seems invalid - E8 in your case, which I haven't seen yet (RTL8710BN is FF, RTL8710BX is F6).

[kuba2k2]

I modified the tool now to wait a little bit after booting RAM code, and to print a special "marker message" so that the tool can detect when the actual data arrives.

Valid output of ltchiptool -vvts soc ambztool (running AmbZTool directly, with verbose mode, serial dump and timing):

``` I [ 0.021] (+0.021s) Available COM ports: I [ 0.034] (+0.013s) |-- COM114 - USB-SERIAL CH340 - wch.cn (1A86/7523) I [ 0.034] (+0.000s) | |-- Selecting this port. To override, use -d/--device I [ 0.034] (+0.000s) |-- COM1 - Communications Port I [ 0.052] (+0.018s) Linking... S [ 0.062] (+0.010s) -> RX: b'\x15' ... S [ 0.604] (+0.049s) -> RX: b'\x15' S [ 0.653] (+0.049s) -> RX: b'\x15' S [ 0.653] (+0.000s) <- TX: '!' S [ 0.653] (+0.000s) <- TX: b'\x05\r' S [ 0.702] (+0.049s) -> RX: b'\x06' V [ 0.702] (+0.000s) -- UART: Port baudrate set to 115200 S [ 0.732] (+0.030s) -> RX: b'\x00' S [ 0.737] (+0.005s) -> RX: b'\x15' ... S [ 0.926] (+0.049s) -> RX: b'\x15' S [ 0.975] (+0.049s) -> RX: b'\x00' S [ 0.980] (+0.005s) -> RX: b'\x15' ... S [ 1.172] (+0.049s) -> RX: b'\x15' S [ 1.172] (+0.000s) <- TX: '!!' S [ 1.172] (+0.000s) <- TX: b'\x07' S [ 1.221] (+0.049s) -> RX: b'\x06' D [ 1.221] (+0.000s) XMODEM: transmitting to 0x10002000 V [ 1.221] (+0.000s) push_timeout(1.0) D [ 1.221] (+0.000s) Begin start sequence, packet_size=128 D [ 1.222] (+0.000s) standard checksum requested (NAK). D [ 1.222] (+0.000s) send: block 1 S [ 1.222] (+0.000s) <- TX: 01 01 FE 00 20 00 10 19 20 00 10 9B 21 00 10 EF .... ... ...!... S [ 1.222] (+0.000s) <- TX: 21 00 10 F5 20 00 10 EF 21 00 10 41 05 00 08 05 !... ...!..A.... S [ 1.222] (+0.000s) <- TX: 48 03 4B 98 47 06 A0 04 49 02 4B 98 47 0F E0 6D H.K.G...I.K.G..m S [ 1.222] (+0.000s) <- TX: 34 00 00 49 EC 00 00 90 01 00 00 10 00 00 00 41 4..I...........A S [ 1.222] (+0.000s) <- TX: 6D 62 5A 54 6F 6F 6C 5F 4D 61 72 6B 65 72 21 03 mbZTool_Marker!. S [ 1.222] (+0.000s) <- TX: 48 F8 21 04 4A 07 23 02 4C A0 47 06 E0 00 00 AE H.!.J.#.L.G..... S [ 1.222] (+0.000s) <- TX: 26 00 00 65 6D 00 00 00 30 00 10 9F 20 03 21 02 &..em...0... .!. S [ 1.222] (+0.000s) <- TX: 4A 01 4B 98 47 03 E0 65 74 00 00 01 30 00 10 03 J.K.G..et...0... S [ 1.222] (+0.000s) <- TX: 48 04 49 01 4B 98 47 D8 H.I.K.G. S [ 1.237] (+0.015s) -> RX: b'\x06' D [ 1.237] (+0.000s) send: block 2 S [ 1.237] (+0.000s) <- TX: 01 02 FD 80 20 00 10 06 E0 00 00 49 EC 00 00 00 .... ......I.... S [ 1.237] (+0.000s) <- TX: 30 00 10 04 00 00 00 02 20 01 4B 98 47 00 00 01 0....... .K.G... S [ 1.237] (+0.000s) <- TX: 09 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.237] (+0.000s) <- TX: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.237] (+0.000s) <- TX: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.238] (+0.001s) <- TX: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.238] (+0.000s) <- TX: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.238] (+0.000s) <- TX: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ S [ 1.238] (+0.000s) <- TX: FF FF FF FF FF FF FF 02 ........ S [ 1.252] (+0.014s) -> RX: b'\x06' D [ 1.252] (+0.000s) send: at EOF D [ 1.252] (+0.000s) sending EOT, awaiting ACK S [ 1.252] (+0.000s) <- TX: b'\x04' I [ 1.252] (+0.000s) Transmission successful (ACK received). V [ 1.252] (+0.000s) pop_timeout() V [ 1.252] (+0.000s) push_timeout(0.1) S [ 1.257] (+0.005s) -> RX: b'\x0c\rxmodem_log_open \n\r\rclose xMode' S [ 1.258] (+0.001s) -> RX: 'm Transfer ...' S [ 1.654] (+0.396s) -> RX: 41 6D 62 5A 54 6F 6F 6C 5F 4D 61 72 6B 65 72 21 AmbZTool_Marker! S [ 1.654] (+0.000s) -> RX: F6 1C 70 15 55 41 52 54 49 4D 47 5F 44 6F 77 6E ..p.UARTIMG_Down S [ 1.656] (+0.002s) -> RX: 'load 2' V [ 1.759] (+0.103s) pop_timeout() V [ 1.759] (+0.000s) -- UART: Port baudrate set to 1500000 S [ 1.784] (+0.025s) -> RX: 'Open xModem Transfer on Log UART...' S [ 1.806] (+0.022s) -> RX: b'\x00' S [ 1.811] (+0.005s) -> RX: b'\x15' ... S [ 2.003] (+0.049s) -> RX: b'\x15' I [ 2.003] (+0.000s) Received chip info: f61c7015 I [ 2.003] (+0.000s) Chip type: RTL8710BX I [ 2.003] (+0.000s) Flash size: 2 MiB I [ 2.003] (+0.000s) Disconnecting... ```

The critical part is here:

S [      1.654] (+0.396s) -> RX: 41 6D 62 5A 54 6F 6F 6C  5F 4D 61 72 6B 65 72 21  AmbZTool_Marker!
S [      1.654] (+0.000s) -> RX: F6 1C 70 15 55 41 52 54  49 4D 47 5F 44 6F 77 6E  ..p.UARTIMG_Down
S [      1.656] (+0.002s) -> RX: 'load 2'

where a delay (of around 400 ms) is added, the marker message is transmitted, the chip ID & flash ID (F6 1C 70 15), and a finishing message.

[hn]

That did the trick! Reading flash seems to work reliably (tested three times, produced identical files). Didn't test flash write (yet).

You cannot dump the flash several times in a row, you have to reset the MCU each time, because the second time it hangs here forever:

V: -- UART: Port baudrate set to 1500000
S: <- TX: b'\x18\x07\x18'
V: -- UART: Port baudrate set to 1500000
S: <- TX: b'\x18\x07\x18'
V: -- UART: Port baudrate set to 1500000
S: <- TX: b'\x18\x07\x18'
V: -- UART: Port baudrate set to 1500000
S: <- TX: b'\x18\x07\x18'
V: -- UART: Port baudrate set to 1500000

If I remember correctly, I can dump/write flash multiple times in a row with rtltool, which is very helpful when you have to pull TX to GND with a paperclip in this case :)