-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid head of packet (0x45): Possible serial noise or corruption...ESP32-C3-MINI (ESPTOOL-872) #983
Comments
Hi @MahadiHasantauhid, |
I can provide several but the most recurring one is |
Could you please try to use esptool.py directly? If you have Python installed on your system, it should be as easy as:
For full installation instructions, please look here. There might be a bug or a regression in the |
|
Thank you. The tool seems to fail when the stub flasher is being uploaded. You can run the same command with the Also, adding the |
|
Your chip is resetting in the middle of the flashing process:
The 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. |
@radimkarnis Thank you very much for the responses so far. 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. |
@radimkarnis |
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.
No, there is a multitude of possible reset reasons, doesn't always have to be a POWERON reset.
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? |
That's is a normal execution log, seems like a pre-loaded app to print the module name and TX power - This is normal execution mode (not download mode) - the app is loaded from the SPI flash memory and executed.
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. |
I have wiped clean the STM32 to check whether this is causing any issues or not. I think the reset reason is changed.
|
Ok and does the flashing issue still persist? This is a normal log of the ESP booting from the SPI flash - no issue here. |
@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. |
@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. |
I tried to flash ESP-AWS-IOT example MQTT/tls_mutual_auth, and flash was successfull. But receiving the following issue |
|
@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 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. |
@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 🙏. |
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 bootmode
rst: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 flash
MINI-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
The text was updated successfully, but these errors were encountered: