search

espressif / esptool

Espressif SoC serial bootloader utility
https://docs.espressif.com/projects/esptool
GNU General Public License v2.0
5.4k stars 1.36k forks source link

Invalid head of packet (0x45): Possible serial noise or corruption...ESP32-C3-MINI (ESPTOOL-872) #983

Closed MahadiHasantauhid closed 1 hour ago

MahadiHasantauhid commented 3 weeks ago

Operating System

Windows11

Esptool Version

esptool.py v4.7.0

Python Version

Python 3.12.3

Chip Description

ESP32-C3-MINI-1

Device Description

The ESP32 C3 MINI module is connected to FTDI Serial to USB Adapter. I was having BROWNOUT RESET while using the 3V pin from the adapter to Power the module. Now I'm using the 5V pin from the adapter to power up mini module, it seems that the BROWNOUT RESET is not happening during reset. But when I try to flash any program I used a switch to pull down the GPIO9 pin to LOW to the enter the bootmoderst:0x1 (POWERON),boot:0x5 (DOWNLOAD(USB/UART0/1)) waiting for download The message I see during Normal Boot mode using Tera Term as follows in ESPTOOL OUTPUT section. I'm trying to flashMINI-1 factory_param.bin` to the module but unfortunately I see the same "Invalid head of packet (0x45): Possible serial noise or corruption" I used VSCode IDE, ESP Flasher TOOL. But same issue persist.

Hardware Configuration

The Module is connected to STM32 Via Uart.

How is Esptool Run

VS Code

Full Esptool Command Line that Was Run

No response

Esptool Output

`ESP-ROM:esp32c3-api1-20210207 Build:Feb 7 2021 rst:0x1 (POWERON),boot:0xd (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:2 load:0x3fcd6100,len:0x18c8 load:0x403ce000,len:0x8d4 load:0x403d0000,len:0x2d6c entry 0x403ce000 I (31) boot: ESP-IDF qa-test-v4.3.3-20220423 2nd stage bootloader I (31) boot: compile time 07:45:53 I (32) boot: chip revision: 4 I (35) boot_comm: chip revision: 4, min. bootloader chip revision: 3 I (42) boot.esp32c3: SPI Speed : 40MHz I (46) boot.esp32c3: SPI Mode : DIO I (51) boot.esp32c3: SPI Flash Size : 4MB I (56) boot: Enabling RNG early entropy source... I (61) boot: Partition Table: I (65) boot: ## Label Usage Type ST Offset Length I (72) boot: 0 otadata OTA data 01 00 0000d000 00002000 I (80) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (87) boot: 2 nvs WiFi data 01 02 00010000 0000e000 I (95) boot: 3 at_customize unknown 40 00 0001e000 00042000 I (102) boot: 4 ota_0 OTA app 00 10 00060000 001d0000 I (110) boot: 5 ota_1 OTA app 00 11 00230000 001d0000 I (117) boot: End of partition table I (121) boot_comm: chip revision: 4, min. application chip revision: 3 I (129) esp_image: segment 0: paddr=00060020 vaddr=3c140020 size=2a620h (173600) map I (175) esp_image: segment 1: paddr=0008a648 vaddr=3fc91200 size=03c6ch ( 15468) load I (179) esp_image: segment 2: paddr=0008e2bc vaddr=40380000 size=01d5ch ( 7516) load I (183) esp_image: segment 3: paddr=00090020 vaddr=42000020 size=133ab0h (1260208) map I (465) esp_image: segment 4: paddr=001c3ad8 vaddr=40381d5c size=0f3c4h ( 62404) load I (480) esp_image: segment 5: paddr=001d2ea4 vaddr=50000000 size=00014h ( 20) load I (481) esp_image: segment 6: paddr=001d2ec0 vaddr=50000018 size=00010h ( 16) load I (492) boot: Loaded app from partition at offset 0x60000 I (492) boot: Disabling RNG early entropy source... module_name:MINI-1 max tx power=78,ret=0

More Information

No response

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

radimkarnis commented 3 weeks ago

Hi @MahadiHasantauhid, please provide a full log from esptool.py (the one ending with Invalid head of packet (0x45): Possible serial noise or corruption). The normal boot log is not relevant to this issue. Thank you.

MahadiHasantauhid commented 2 weeks ago

I can provide several but the most recurring one is Invalid head of packet (0x45): Possible serial noise or corruption. As follows: Uploading stub... Running stub... Stub running... Changing baud rate to 115200 Invalid head of packet (0x45): Possible serial noise or corruption. [2024-06-04 15:56:17,242][ESP8266Loader_spi[1]][espDownloader.py][line:782][ERROR]: ESP32C3 Chip stub error esp_stub_and_set_baud. no log file output ... . Uploading stub... Invalid head of packet (0x45): Possible serial noise or corruption. [2024-06-04 15:57:01,242][ESP8266Loader_spi[1]][espDownloader.py][line:782][ERROR]: ESP32C3 Chip stub error esp_stub_and_set_baud. no log file output ... test offset : 0 0x0 case ok test offset : 0 0x0 case ok . this log is taken from flash_download_tool_3.9.6

radimkarnis commented 2 weeks ago

Could you please try to use esptool.py directly?

If you have Python installed on your system, it should be as easy as:

pip install esptool
esptool write_flash factory_param.bin

For full installation instructions, please look here.

There might be a bug or a regression in the flash_download_tool app, or it is using an old version of esptool.py. The only way we can be sure you are using the latest release with all of the recent bug fixes is to use the Python package (or at least the latest Windows executable: esptool-v4.7.0-win64.zip)

MahadiHasantauhid commented 2 weeks ago 
esptool.py v4.7.0
Serial port COM5
Connecting.........
Chip is ESP32-C3 (QFN32) (revision v0.4)
Features: WiFi, BLE, Embedded Flash 4MB (XMC)
Crystal is 40MHz
MAC: ec:da:3b:a5:bc:c4
Uploading stub...

A fatal error occurred: Invalid head of packet (0x45): Possible serial noise or corruption. This is the error I kept receiving for the command esptool --chip esp32c3 --port COM5 --baud 115200 write_flash 0x0 factory_MINI-1.bin I checked also for baud rate 9600.

radimkarnis commented 2 weeks ago

Thank you. The tool seems to fail when the stub flasher is being uploaded. You can run the same command with the --no-stub option after esptool.py to skip this part and see if this helps.

Also, adding the --trace option will show us more diagnostic information!

MahadiHasantauhid commented 2 weeks ago 
`  esptool.py v4.7.0
Serial port COM5
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU
TRACE +0.001 Write 46 bytes:
    c000082400000000 0007071220555555 | ...$........ UUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
TRACE +0.108 No serial data received.
.TRACE +0.060 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU
TRACE +0.001 Write 46 bytes:
    c000082400000000 0007071220555555 | ...$........ UUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
TRACE +0.027 Read 1 bytes: c0
TRACE +0.001 Read 111 bytes:
    0108040007071220 00000000c0c00108 | ....... ........
    0400070712200000 0000c0c001080400 | ..... ..........
    0707122000000000 c0c0010804000707 | ... ............
    122000000000c0c0 0108040007071220 | . .............
    00000000c0c00108 0400070712200000 | ............. ..
    0000c0c001080400 0707122000000000 | ........... ....
    c0c0010804000707 122000000000c0   | ......... .....
TRACE +0.001 Received full packet: 010804000707122000000000
TRACE +0.010 Received full packet: 010804000707122000000000
TRACE +0.012 Received full packet: 010804000707122000000000
TRACE +0.013 Received full packet: 010804000707122000000000
TRACE +0.011 Received full packet: 010804000707122000000000
TRACE +0.012 Received full packet: 010804000707122000000000
TRACE +0.012 Received full packet: 010804000707122000000000
TRACE +0.012 Received full packet: 010804000707122000000000

TRACE +0.012 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=00100040
TRACE +0.000 Write 14 bytes: c0000a04000000000000100040c0
TRACE +0.015 Read 1 bytes: c0
TRACE +0.001 Read 13 bytes: 010a04006f50311b00000000c0
TRACE +0.000 Received full packet: 010a04006f50311b00000000
TRACE +0.011 command op=0x14 data len=0 wait_response=1 timeout=3.000 data=
TRACE +0.000 Write 10 bytes: c00014000000000000c0
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 27 bytes:
    011418006f50311b 0000000000000000 | ....oP1.........
    0000000c05000000 030000           | ...........
TRACE +0.015 Read 1 bytes: 00
TRACE +0.000 Read 5 bytes: 00000000c0
TRACE +0.001 Received full packet:
    011418006f50311b 0000000000000000 | ....oP1.........
    0000000c05000000 0300000000000000 | ................
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=7cf0cd3f
TRACE +0.001 Write 14 bytes: c0000a0400000000007cf0cd3fc0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 010a040000000000000000
TRACE +0.016 Read 1 bytes: 00
TRACE +0.000 Read 1 bytes: c0
TRACE +0.000 Received full packet: 010a04000000000000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=50880060
TRACE +0.001 Write 14 bytes: c0000a04000000000050880060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000108b00000000c0
TRACE +0.000 Received full packet: 010a04000000108b00000000
TRACE +0.012 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=58880060
TRACE +0.000 Write 14 bytes: c0000a04000000000058880060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a0400b10a070000000000c0
TRACE +0.000 Received full packet: 010a0400b10a070000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=58880060
TRACE +0.000 Write 14 bytes: c0000a04000000000058880060c0
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a0400b10a070000000000c0
TRACE +0.000 Received full packet: 010a0400b10a070000000000
TRACE +0.012 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=50880060
TRACE +0.000 Write 14 bytes: c0000a04000000000050880060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000108b00000000c0
TRACE +0.000 Received full packet: 010a04000000108b00000000
Chip is ESP32-C3 (QFN32) (revision v0.4)
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=50880060
TRACE +0.000 Write 14 bytes: c0000a04000000000050880060c0
TRACE +0.006 Read 1 bytes: c0
TRACE +0.002 Read 13 bytes: 010a04000000108b00000000c0
TRACE +0.000 Received full packet: 010a04000000108b00000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=54880060
TRACE +0.000 Write 14 bytes: c0000a04000000000054880060c0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 8 bytes: 010a0400f9a27210
TRACE +0.015 Read 1 bytes: 00
TRACE +0.001 Read 4 bytes: 000000c0
TRACE +0.001 Received full packet: 010a0400f9a2721000000000
Features: WiFi, BLE, Embedded Flash 4MB (XMC)
Crystal is 40MHz
TRACE +0.010 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=44880060
TRACE +0.001 Write 14 bytes: c0000a04000000000044880060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a0400c4bca53b00000000c0
TRACE +0.000 Received full packet: 010a0400c4bca53b00000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=48880060
TRACE +0.000 Write 14 bytes: c0000a04000000000048880060c0
TRACE +0.005 Read 1 bytes: c0
TRACE +0.001 Read 13 bytes: 010a0400daec000000000000c0
TRACE +0.000 Received full packet: 010a0400daec000000000000
MAC: ec:da:3b:a5:bc:c4
Enabling default SPI flash mode...
TRACE +0.010 command op=0x0d data len=8 wait_response=1 timeout=3.000 data=0000000000000000
TRACE +0.000 Write 18 bytes:
    c0000d0800000000 0000000000000000 | ................
    00c0                              | ..
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010d0400daec000000000000c0
TRACE +0.000 Received full packet: 010d0400daec000000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=18200060
TRACE +0.001 Write 14 bytes: c0000a04000000000018200060c0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000008000000000c0
TRACE +0.000 Received full packet: 010a04000000008000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=20200060
TRACE +0.001 Write 14 bytes: c0000a04000000000020200060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.001 Read 13 bytes: 010a04000000007000000000c0
TRACE +0.000 Received full packet: 010a04000000007000000000
TRACE +0.010 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=2820006017000000ffffffff00000000
TRACE +0.001 Write 26 bytes:
    c000091000000000 0028200060170000 | .........( .`...
    00ffffffff000000 00c0             | ..........
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904000000007000000000c0
TRACE +0.000 Received full packet: 010904000000007000000000
TRACE +0.011 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=1820006000000090ffffffff00000000
TRACE +0.001 Write 26 bytes:
    c000091000000000 0018200060000000 | .......... .`...
    90ffffffff000000 00c0             | ..........
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904000000007000000000c0
TRACE +0.000 Received full packet: 010904000000007000000000
TRACE +0.011 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=202000609f000070ffffffff00000000
TRACE +0.000 Write 26 bytes:
    c000091000000000 00202000609f0000 | .........  .`...
    70ffffffff000000 00c0             | p.........
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904000000007000000000c0
TRACE +0.000 Received full packet: 010904000000007000000000
TRACE +0.011 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=5820006000000000ffffffff00000000
TRACE +0.000 Write 26 bytes:
    c000091000000000 0058200060000000 | .........X .`...
    00ffffffff000000 00c0             | ..........
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904000000007000000000c0
TRACE +0.000 Received full packet: 010904000000007000000000
TRACE +0.010 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=0020006000000400ffffffff00000000
TRACE +0.000 Write 26 bytes:
    c000091000000000 0000200060000004 | .......... .`...
    00ffffffff000000 00c0             | ..........
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904000000007000000000c0
TRACE +0.001 Received full packet: 010904000000007000000000
TRACE +0.010 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=00200060
TRACE +0.001 Write 14 bytes: c0000a04000000000000200060c0
TRACE +0.006 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000000000000000c0
TRACE +0.000 Received full packet: 010a04000000000000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=58200060
TRACE +0.000 Write 14 bytes: c0000a04000000000058200060c0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04002040160000000000c0
TRACE +0.000 Received full packet: 010a04002040160000000000
TRACE +0.011 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=1820006000000080ffffffff00000000
TRACE +0.001 Write 26 bytes:
    c000091000000000 0018200060000000 | .......... .`...
    80ffffffff000000 00c0             | ..........
TRACE +0.004 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 0109040020401600000000
TRACE +0.015 Read 1 bytes: 00
TRACE +0.001 Read 1 bytes: c0
TRACE +0.000 Received full packet: 010904002040160000000000
TRACE +0.011 command op=0x09 data len=16 wait_response=1 timeout=3.000 data=2020006000000070ffffffff00000000
TRACE +0.000 Write 26 bytes:
    c000091000000000 0020200060000000 | .........  .`...
    70ffffffff000000 00c0             | p.........
TRACE +0.005 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010904002040160000000000c0
TRACE +0.000 Received full packet: 010904002040160000000000
Configuring flash size...
TRACE +0.011 command op=0x0b data len=24 wait_response=1 timeout=3.000 data=
    0000000000004000 0000010000100000 | ......@.........
    00010000ffff0000                  | ........
TRACE +0.001 Write 34 bytes:
    c0000b1800000000 0000000000000040 | ...............@
    0000000100001000 0000010000ffff00 | ................
    00c0                              | ..
TRACE +0.004 Read 1 bytes: c0
TRACE +0.016 Read 1 bytes: 01
TRACE +0.000 Read 12 bytes: 0b04002040160000000000c0
TRACE +0.001 Received full packet: 010b04002040160000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=38880060
TRACE +0.000 Write 14 bytes: c0000a04000000000038880060c0
TRACE +0.004 Read 1 bytes: c0
TRACE +0.001 Read 13 bytes: 010a04000000000000000000c0
TRACE +0.000 Received full packet: 010a04000000000000000000
TRACE +0.011 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=58880060
TRACE +0.000 Write 14 bytes: c0000a04000000000058880060c0
TRACE +0.132 Read 1 bytes: 45
TRACE +0.000 Read invalid data: 45
TRACE +0.000 Remaining data in serial buffer:
    53502d524f4d3a65 7370333263332d61 | SP-ROM:esp32c3-a
    7069312d32303231 303230370d0a     | pi1-20210207..

A fatal error occurred: Invalid head of packet (0x45): Possible serial noise or corruption. `  
Command : `esptool --chip esp32c3 --port COM5 --baud 115200 --no-stub --trace write_flash 0x0 factory_MINI-1.bin  `
radimkarnis commented 2 weeks ago

Your chip is resetting in the middle of the flashing process:

 53502d524f4d3a65 7370333263332d61 | SP-ROM:esp32c3-a
 7069312d32303231 303230370d0a     | pi1-20210207..

The ESP-ROM:esp32c3-api1-20210207 snippet is a part of the boot log - that appears after a reset.

Now, we don't see the reason why the reset is happening. It could be an insufficient power supply, a faulty unit, or a stray watchdog resetting the chip.

To find out why this happens, we need to capture the reset reason, which is mentioned later in the boot log (e.g. rst:0x1 (POWERON_RESET)). One way to do this is to try flashing over the internal USB-Serial/JTAG peripheral and listen over your FTDI Serial to USB Adapter at the same time - here you should see the full output (if the issue still happens when USB-Serial/JTAG is used).

MahadiHasantauhid commented 2 weeks ago

Your chip is resetting in the middle of the flashing process:

 53502d524f4d3a65 7370333263332d61 | SP-ROM:esp32c3-a
 7069312d32303231 303230370d0a     | pi1-20210207..

The ESP-ROM:esp32c3-api1-20210207 snippet is a part of the boot log - that appears after a reset.

Now, we don't see the reason why the reset is happening. It could be an insufficient power supply, a faulty unit, or a stray watchdog resetting the chip.

To find out why this happens, we need to capture the reset reason, which is mentioned later in the boot log (e.g. rst:0x1 (POWERON_RESET)). One way to do this is to try flashing over the internal USB-Serial/JTAG peripheral and listen over your FTDI Serial to USB Adapter at the same time - here you should see the full output (if the issue still happens when USB-Serial/JTAG is used).

@radimkarnis Thank you very much for the responses so far. I was experiencing BROWNOUT_RESET while the module was powered 3V from the FTDI Adapter, But now I'm giving 5V just to get rid of that issue. For a time being BROWNOUT_RESET is averted, I also checked the insufficient power issue from the Manual where it is mentioned- VDD3P3_CPU,VDD3P3_RTC, VDDA1 and VDDA2 should have more than 2.7V Threshold Voltage in order to avoid BROWNOUT_RESET. I will change the USB Cable as well to see whether it is not an issue(Length=1meter).

Unfortunately, this module is attached to another host MCU by Uart connection. I'm using TXDO, RXDO (Pin 30 &31) to flash the firmware into it. FTDI DTR connected to GPIO9 and EN is left floating to get the DOWNLOAD BOOT MODE. But I never had this rst:0x1 (POWERON_RESET) mode till now while checking with TERA TERA or PUTTY, it is Always rst:0x1 (POWERON) while on download mode, is it similar type definition?

it keeps continuously coming to serial terminal both in Teraterm, PUTTY and VS Code. Is it normal to get the messages continuously on terminal or just once while it resets? But I suspected that the Error type is related to chip reset while flashing according to the Troubleshooting guide.

MahadiHasantauhid commented 2 weeks ago

@radimkarnis I have tried changing the usb cable but with no effect. The problem is the same chip reset in the middle of flash. So I'm leaving the USB Cable issue out of the question now. How to capture this reset reason and listen over FTDI serial to USB adapter? I don't have the pinouts available for me to try the internal USB-Serial/JTAG peripherals. Is there any other way to try it?

radimkarnis commented 2 weeks ago

Unfortunately, this module is attached to another host MCU by Uart connection

Is it possible to try flashing without this connection? Can you fully disable the other MCU while flashing? There is a possibility of the other MCU interfering with the serial connection.

it is Always rst:0x1 (POWERON) while on download mode, is it similar type definition?

No, there is a multitude of possible reset reasons, doesn't always have to be a POWERON reset.

FTDI DTR connected to GPIO9 and EN is left floating to get the DOWNLOAD BOOT MODE

EN left floating seems suspicious. Usually, it is connected to the FTDI RTS, which pulls EN low to reset the chip when needed. How do you enter the download mode, do you do it manually? Pulling EN low and then high triggers the POWERON reset.

If you keep it floating (not really floating, there is an internal pull-up resistor keeping EN high when not used) during flashing, is any of your other HW interfacing with the EN pin?

MahadiHasantauhid commented 1 week ago

1719238804131 The device comes with this STM32 host MCU connected via Uart. Unfortunate, it is not possible to free up the ESP32-C3. Even though this UART connection is done on pins (pins 18&19) while I'm trying to flash the code using pins ( 30&31).

Actually, The EN Pin in connected to a switch with the ground using 10k resistor and also it is connected to GPIO Pin of STM32, I used the FTDI RTS pin and connected it, but that doesn't have any impact at all. Unless switch is pressed the EN remain. As per schematics it is connected to 3.3v with 10k pull up resistor as you know. POWERON reset doesn't require anything for this module. Even if the button is not pressed I still get the POWERON reset. EN does have GPIO of STM32 interfacing in this module. GPIO9 is connected to DTR pin to activate download mode. Even without DTR pin, I hooked GPIO9 pin to ground using switch to activate same download mode. rst:0x1 (POWERON),boot:0x5 (DOWNLOAD(USB/UART0/1)) waiting for download .

The message log mentioned in my first message keeps continuously pops up on serial terminal of Tera Term or Putty. Does that mean that the module keeps resetting? or is it normal a normal message Log?

radimkarnis commented 1 week ago

The message log mentioned in my first message keeps continuously pops up on serial terminal of Tera Term or Putty. Does that mean that the module keeps resetting? or is it normal a normal message Log?

That's is a normal execution log, seems like a pre-loaded app to print the module name and TX power - ESP-ROM:esp32c3-api1-20210207 - ROM bootloader runs I (31) boot: ESP-IDF qa-test-v4.3.3-20220423 2nd stage bootloader - 2nd stage bootloader runs (this is built by ESP-IDF) module_name:MINI-1 - the app runs

This is normal execution mode (not download mode) - the app is loaded from the SPI flash memory and executed.

EN does have GPIO of STM32 interfacing in this module.

Is there a chance the STM32 is resetting the ESP? If the GPIO pulls the EN pin of the ESP to GND, it will reset.

I am sorry, but at this point I don't know how else to help you. I believe this is a HW issue that's causing your chip to reset. Having the ESP32-C3 being a part of a bigger device with other MCUs on it makes things even harder to debug. I advise you to study the boot mode selection guide and check if everything is ok and the EN pin is not getting asserted by the other MCU.

MahadiHasantauhid commented 1 week ago

I have wiped clean the STM32 to check whether this is causing any issues or not. I think the reset reason is changed.

ESP-ROM:esp32c3-api1-20210207 Build:Feb 7 2021 rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT) Saved PC:0x403d1512 SPIWP:0xee mode:DIO, clock div:2 load:0x3fcd6100,len:0x18c8 load:0x403ce000,len:0x8d4 load:0x403d0000,len:0x2d6c entry 0x403ce000 I (35) boot: ESP-IDF qa-test-v4.3.3-20220423 2nd stage bootloader I (35) boot: compile time 07:45:53 I (35) boot: chip revision: 4 I (38) boot_comm: chip revision: 4, min. bootloader chip revision: 3 I (45) boot.esp32c3: SPI Speed : 40MHz I (50) boot.esp32c3: SPI Mode : DIO I (55) boot.esp32c3: SPI Flash Size : 4MB I (59) boot: Enabling RNG early entropy source... I (65) boot: Partition Table: I (68) boot: ## Label Usage Type ST Offset Length I (76) boot: 0 otadata OTA data 01 00 0000d000 00002000 I (83) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (91) boot: 2 nvs WiFi data 01 02 00010000 0000e000 I (98) boot: 3 at_customize unknown 40 00 0001e000 00042000 I (106) boot: 4 ota_0 OTA app 00 10 00060000 001d0000 I (113) boot: 5 ota_1 OTA app 00 11 00230000 001d0000 I (121) boot: End of partition table I (125) boot: No factory image, trying OTA 0 E (130) esp_image: image at 0x60000 has invalid magic byte (nothing flashed here?) E (138) boot: OTA app partition slot 0 is not bootable E (144) esp_image: image at 0x230000 has invalid magic byte (nothing flashed here?) E (152) boot: OTA app partition slot 1 is not bootable E (158) boot: No bootable app partitions in the partition table

radimkarnis commented 1 week ago

Ok and does the flashing issue still persist? This is a normal log of the ESP booting from the SPI flash - no issue here.

MahadiHasantauhid commented 1 week ago

@radimkarnis I flashed the module and got it connected to the wifi. I think you are right, somehow STM32 was causing this issue. I will have be sure by checking the code that was flashed into STM32. Thank you very much for your kind support. I will investigate further.

radimkarnis commented 1 week ago

@MahadiHasantauhid Great, I am glad we could make some progress!

Ultimately - I think we can agree that this is not an esptool.py issue, but a hardware one. Do you agree to close this issue? If you find more information, you can always write it here for future generations to see.

MahadiHasantauhid commented 1 week ago

I tried to flash ESP-AWS-IOT example MQTT/tls_mutual_auth, and flash was successfull. But receiving the following issue Build:Feb 7 2021 rst:0xc (RTC_SW_CPU_RST),boot:0xd (SPI_FAST_FLASH_BOOT) Saved PC:0x403808e2 SPIWP:0xee mode:DIO, clock div:1 load:0x3fcd5820,len:0x170c load:0x403cc710,len:0x968 load:0x403ce710,len:0x2f9c entry 0x403cc710 I (35) boot: ESP-IDF v5.1.4-dirty 2nd stage bootloader I (35) boot: compile time Jul 1 2024 09:52:00 I (35) boot: chip revision: v0.4 I (39) boot.esp32c3: SPI Speed : 80MHz I (43) boot.esp32c3: SPI Mode : DIO I (48) boot.esp32c3: SPI Flash Size : 2MB I (53) boot: Enabling RNG early entropy source... I (58) boot: Partition Table: I (62) boot: ## Label Usage Type ST Offset Length I (69) boot: 0 esp_secure_cert unknown 3f 06 0000d000 00002000 I (77) boot: 1 nvs WiFi data 01 02 0000f000 00009000 I (84) boot: 2 phy_init RF data 01 01 00018000 00001000 I (91) boot: 3 factory factory app 00 00 00020000 00100000 I (99) boot: End of partition table I (103) esp_image: segment 0: paddr=00020020 vaddr=3c0b0020 size=28060h (163936) map I (138) esp_image: segment 1: paddr=00048088 vaddr=3fc91400 size=02b04h ( 11012) load I (141) esp_image: segment 2: paddr=0004ab94 vaddr=40380000 size=05484h ( 21636) load I (148) esp_image: segment 3: paddr=00050020 vaddr=42000020 size=a9a90h (694928) map I (265) esp_image: segment 4: paddr=000f9ab8 vaddr=40385484 size=0bdb4h ( 48564) load I (280) boot: Loaded app from partition at offset 0x20000 I (280) boot: Disabling RNG early entropy source... I (292) cpu_start: Unicore app I (292) cpu_start: Pro cpu up. I (301) cpu_start: Pro cpu start user code I (301) cpu_start: cpu freq: 160000000 Hz I (301) cpu_start: Application information: I (304) cpu_start: Project name: tls_mutual_auth I (309) cpu_start: App version: 202210.01-LTS-release-14-g40feb I (316) cpu_start: Compile time: Jul 1 2024 10:28:17 I (323) cpu_start: ELF file SHA256: c7db97a3af42ce2c... I (328) cpu_start: ESP-IDF: v5.1.4-dirty I (334) cpu_start: Min chip rev: v0.3 I (339) cpu_start: Max chip rev: v1.99 I (343) cpu_start: Chip rev: v0.4 I (348) heap_init: Initializing. RAM available for dynamic allocation: I (355) heap_init: At 3FC98B90 len 00027470 (157 KiB): DRAM I (362) heap_init: At 3FCC0000 len 0001C710 (113 KiB): DRAM/RETENTION I (369) heap_init: At 3FCDC710 len 00002950 (10 KiB): DRAM/RETENTION/STACK I (376) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM I (383) spi_flash: detected chip: generic I (387) spi_flash: flash io: dio W (391) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (405) sleep: Configure to isolate all GPIO pins in sleep state I (411) sleep: Enable automatic switching of GPIO sleep configuration I (418) app_start: Starting scheduler on CPU0 I (423) main_task: Started on CPU0 I (423) main_task: Calling app_main() I (423) MQTT_EXAMPLE: [APP] Startup.. I (433) MQTT_EXAMPLE: [APP] Free memory: 279964 bytes I (433) MQTT_EXAMPLE: [APP] IDF version: v5.1.4-dirty I (443) example_connect: Start example_connect. I (443) pp: pp rom version: 9387209 I (453) net80211: net80211 rom version: 9387209 I (463) wifi:wifi driver task: 3fca12b4, prio:23, stack:6656, core=0 I (463) wifi:wifi firmware version: 3ce09e5 I (463) wifi:wifi certification version: v7.0 I (473) wifi:config NVS flash: enabled I (473) wifi:config nano formating: disabled I (483) wifi:Init data frame dynamic rx buffer num: 32 I (483) wifi:Init static rx mgmt buffer num: 5 I (483) wifi:Init management short buffer num: 32 I (493) wifi:Init dynamic tx buffer num: 32 I (493) wifi:Init static tx FG buffer num: 2 I (503) wifi:Init static rx buffer size: 1600 I (503) wifi:Init static rx buffer num: 10 I (503) wifi:Init dynamic rx buffer num: 32 I (513) wifi_init: rx ba win: 6 I (513) wifi_init: tcpip mbox: 32 I (523) wifi_init: udp mbox: 6 I (523) wifi_init: tcp mbox: 6 I (523) wifi_init: tcp tx win: 5760 I (533) wifi_init: tcp rx win: 5760 I (533) wifi_init: tcp mss: 1440 I (543) wifi_init: WiFi IRAM OP enabled I (543) wifi_init: WiFi RX IRAM OP enabled I (553) phy_init: phy_�,Apr 3p��4,10:49:24 I BOD: Brownout detector was triggered I think at some point Brownout reset is triggered. Simple wifi station example program was just running fine previously. Still the STM32 is clean, no interference yet i guess. Do you see anything out of the ordinary from the log file? @radimkarnis

MahadiHasantauhid commented 1 week ago

E (230638) coreMQTT: sendBuffer: Unable to send packet: Network Error. E (230648) coreMQTT: Transport send failed for DISCONNECT packet. E (230658) coreMQTT: Sending MQTT DISCONNECT failed with status=MQTTSendFailed. this is the latest issue after successfully flashing the ESP-AWS-IOT example code mqtt/tls_mutual_authentication...

radimkarnis commented 59 minutes ago

@MahadiHasantauhid I am sorry, but this is not an esptool issue anymore. I am not able to debug your application logs or solve hardware issues.

I advise you to focus on the brownout detector triggering. I believe your custom hardware has insufficient power supply or other power delivery issues, that's why you are seeing Brownout detector was triggered.

You can also use our free-of-charge schematic and PCB review service to check the PCB and design.

For these reasons, we are now closing the issue.

MahadiHasantauhid commented 29 minutes ago

@radimkarnis I would like to thank you for the support so far. You're right. The issues are related to hardware. Can't thank you enough for the support 🙏.