Can't read the 16mb of flash in Arduino Nesso-N1 (ESP32-C6 QFN40 v0.2) (ESPTOOL-1218)

[tyeth]

Operating System

win11

Esptool Version

5.1.0

Python Version

3.14 but not necessarily what's used

Chip Description

ESP32-C6 rev0.2 QFN40 16MB flash

Device Description

Fails to successfully read the full 16mb.

Using command:
esptool.exe --baud 115200 read-flash 0x0 0x1000000 nesso-n1.bin
Also tried with 460800, 921600, and not specifying baud rate.

Fetching just 4mb of flash was able to succeed at least once (although done via esptool-js).

Attempting to fetch the full 16mb failed on every occasion with current data transfer at random percentages.
Changing to the worlds shortest USB-C cable made no difference.

Hardware Configuration

It's a plain stock Arduino Nesso-N1.
https://store.arduino.cc/products/nesso-n1

How is Esptool Run

esptool.exe from a powershell windows terminal session

Full Esptool Command Line that Was Run

esptool.exe --baud 115200 read-flash 0x0 0x1000000 nesso-n1.bin

Esptool Output

C:\Users\tyeth> esptool.exe read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.

Configuring flash size...
Reading from 0x00824000 [==============>               ]  50.9% 8536064/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Packet content transfer stopped
C:\Users\tyeth> esptool.exe read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.

Configuring flash size...
Reading from 0x002c2000 [====>                         ]  17.2% 2891776/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xf0a bytes.
C:\Users\tyeth> esptool.exe read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.

Configuring flash size...
Reading from 0x0075a000 [============>                 ]  45.9% 7708672/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xd23 bytes.
C:\Users\tyeth> esptool.exe --baud 115200 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.

Configuring flash size...
Reading from 0x0019c000 [==>                           ]  10.1% 1687552/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xe7e bytes.
C:\Users\tyeth> esptool.exe --baudrate 115200 read-flash 0x0 0x1000000 nesso-n1.bin

 Usage: esptool [OPTIONS] COMMAND [ARGS]...

 Try 'esptool -h' for help
╭─ Error ──────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ No such option: --baudrate Did you mean --baud?                                                                      │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

C:\Users\tyeth> esptool.exe --baud 916200 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.
Changing baud rate to 916200...
Changed.

Configuring flash size...
Reading from 0x00678000 [===========>                  ]  40.4% 6782976/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xc9d bytes.
C:\Users\tyeth> esptool.exe --baud 460800 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.
Changing baud rate to 460800...
Changed.

Configuring flash size...
Reading from 0x00290000 [===>                          ]  16.0% 2686976/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xe1a bytes.
C:\Users\tyeth> esptool.exe --baud 921600 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.
Changing baud rate to 921600...
Changed.

Configuring flash size...
Reading from 0x00238000 [===>                          ]  13.9% 2326528/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xd87 bytes.
C:\Users\tyeth> esptool.exe --baud 921600 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.
Changing baud rate to 921600...
Changed.

Configuring flash size...
Reading from 0x003ea000 [======>                       ]  24.5% 4104192/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xf2d bytes.
C:\Users\tyeth> esptool.exe --baud 115200 read-flash 0x0 0x1000000 nesso-n1.bin
esptool v5.1.0
Connected to ESP32-C6 on COM101:
Chip type:          ESP32-C6 (QFN40) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:8c:81:ff:fe:50:2c:a8
BASE MAC:           58:8c:81:50:2c:a8
MAC_EXT:            ff:fe

Stub flasher running.

Configuring flash size...
Reading from 0x0041b000 [======>                       ]  25.7% 4304896/16777216 bytes...
Hard resetting via RTS pin...

A fatal error occurred: Corrupt data, expected 0x1000 bytes but received 0xf93 bytes.

More Information

No response

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[github-actions]

Hi @tyeth! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Based on the esptool docs and ESP32‑C6 resources you shared, there are two main points we can rely on:

1. The esptool read-flash flow & protocol are the same for ESP32‑C6 as other chips
   The read-flash command is supported on ESP32‑C6 and is intended to read arbitrary regions, including the entire flash when the size argument is large enough. [ESP32‑C6 read‑flash]
   For ESP32/ESP32‑C6, esptool normally uses a stub loader READ_FLASH command, which streams data over the serial link as raw SLIP packets and requires continuous, error‑free reception until completion. [ESP32 serial protocol; ESP32‑C6 serial protocol]

   This means that:

   • Any disturbance on the serial link (USB/serial glitches, host side interruptions, etc.) will cause the host to receive less than the expected 0x1000‑byte chunk, which matches your error expected 0x1000 bytes but received 0x… bytes.
   • When this happens, esptool reports “Corrupt data” or “Packet content transfer stopped” and aborts.

2. The official troubleshooting guidance for intermittent flashing/read errors
   When flash operations fail part‑way through with random errors, Espressif’s esptool docs recommend:

   • Lowering the baud rate further (even down to very low values) to exclude line‑rate issues. [ESP32‑C6 troubleshooting]
   • Checking power stability and board‑side hardware conditions. Insufficient or unstable power can cause the chip to reset or misbehave during long transfers. [ESP32‑C6 troubleshooting]

Given the above, the behavior you see (random failure percentages, short reads vs expected 0x1000, “Hard resetting via RTS pin…”) is consistent with communication or stability issues during a long continuous transfer, not with a protocol limitation at 16 MB. The knowledge sources do not mention any limit or known issue specific to 16 MB flash on ESP32‑C6, nor any errata for rev 0.2 affecting read-flash. The PCN for ESP32‑C6 v0.2 only describes metal‑layer fixes and a flash‑part change for ESP32‑C6FH4, with no mention of read‑flash limitations. [ESP32‑C6 PCN]

From the available documentation, here are the concrete actions that are supported by the docs and that you can suggest in the GitHub issue:

1. Try an even lower baud rate for the whole transfer
   The troubleshooting guide explicitly suggests using a very slow baud rate when there are intermittent failures (they give 9600 as a “very slow” test value). [ESP32‑C6 troubleshooting]
   For example:

   esptool.exe -p COM101 -b 9600 read-flash 0x0 0x1000000 nesso-n1.bin

   This is slow, but it helps verify if the issue is purely link‑rate related.

2. Use the ROM loader instead of the stub flasher (slower but more conservative)
   The docs mention that the ROM loader’s flash read command is “more normal but also much slower” than the stub loader. [ESP32 serial protocol; ESP32‑C6 serial protocol]
   You can force esptool to avoid the stub with --no-stub and, if needed, specify flash size explicitly:

   esptool.exe -p COM101 --baud 115200 --no-stub --flash-size 16MB read-flash 0x0 0x1000000 nesso-n1.bin

   When using --no-stub, the docs explicitly say setting --flash-size may be necessary for proper reading by the ROM. [ESP32‑C6 read‑flash]

3. Verify that esptool sees 16 MB and the SPI flash responds properly
   Use flash-id to confirm that the flash is detected and that esptool reports 16 MB:

   esptool.exe -p COM101 flash-id

   This should print the manufacturer, device ID, and detected flash size. [ESP32‑C6 flash‑id]
   If this does not show 16 MB, that would indicate a board‑side or configuration discrepancy.

4. General stability checks (per esptool troubleshooting)
   Even though this is an Arduino board (not an Espressif devkit), the usual checks still apply: ensure:

   • No other software is accessing the same COM port.
   • The USB port and cable supply stable 5 V and the board’s 3.3 V rail is stable during a long, continuous transfer. [ESP32‑C6 troubleshooting; ESP32‑C6 troubleshooting]

Limitations:
The supplied Espressif documents do not contain Arduino Nesso‑N1‑specific schematics or any board‑specific errata, nor do they describe a known esptool bug specific to ESP32‑C6 rev 0.2 or 16 MB reads. So beyond the protocol/command behavior and generic troubleshooting above, I cannot point to a documented chip or tool defect. If the issue persists after trying --no-stub at a low baud rate and confirming the flash ID, it would be reasonable to ask for a logic/USB trace or to cross‑test on another host, but this is not covered in the provided documentation.

[dobairoland]

@tyeth The automated suggestions looks good. Probably this will not be an esptool issue but a hardware one (as you can see that in each run if fails at different point). One more idea not mentioned above is to change the Windows driver for the serial port.

[radimkarnis]

@tyeth I tried reproducing this issue with many of my available C6 boards (I don't have the exact same devkit to test), but couldn't. Reading flash works and is stable.

Your situation, as mentioned by Roland, seems to be caused by the HW. I am not sure if the peripherals of the nesso devkit could cause such interference.

Does flashing work? Do the same issues occur if you disable the stub flasher (--no-stub)?

[tyeth]

Was no better or Worse [just gets 7068 bytes each time] with disabled stub flasher. Can't remember exactly so will recreate later.

Might be worth picking one up as might be a popular board.

I don't deny it's likely connection stability, as it's a lot to read with no retries on failed blocks.

I cracked the baud up and got as far as 81 and 87 percent at best. Down didn't help.

Reluctant to switch drivers, pretty sure the other C6's I have work as expected, but might have a go at some point of our firmware ever needs more than the 4mb or users experience issues.

I guess I'll just read it in chunks and cat them together with some extra retry logic, and similar thinking ahead to the web tool [esptool-js]

[tyeth]

Curiously it's behaving nicely with another day/cable/laptop-charger/firmware. Same board. Using the web version of esptool-js.
Closing this as transient, but it would be great if the esptool could resume/retry downloads like it now retries uploads.