Open LuisCRSousa opened 1 year ago
radimkarnis
commented
1 year ago Hello @LuisCRSousa, are you connecting the classic way (through a USB-Serial bridge), or with the USB-Serial/JTAG peripheral?
One thing to try is to "erase" the flash by writing a large binary containing only FFs with the --no-stub argument. If everything starts to work after that, this is definitely something we should look into.
LuisCRSousa
commented
1 year ago Hello @LuisCRSousa, are you connecting the classic way (through a USB-Serial bridge), or with the USB-Serial/JTAG peripheral?
USB-Serial/JTAG peripheral
One thing to try is to "erase" the flash by writing a large binary containing only
FFs with the --no-stub argument. If everything starts to work after that, this is definitely something we should look into.
It worked! Actually, I didn't flash 'FF', but used an Arduino example output and flashed the binary manually using the --no-stub option. Now the 'erase_flash' also works.
Thanks a lot.
But why did it worked this way?
LuisCRSousa
commented
1 year ago I was able to replicate the issue again.
Steps: 1- Flash the ASCIITable arduino example with these lines removed. It flashes successfully
// if printed last visible character '~' or 126, stop:
if (thisByte == 126) { // you could also use if (thisByte == '~') {
// This loop loops forever and does nothing
while (true) {
continue;
}
}2 - Try to program again. It gets stuck on 'Stub running'. The last flash still runs on the board. 3 - Flash again with --no-stub argument. It works. 4 - Flash works again without --no-stub argument
Looks like when Serial.print send a lot of data to the console, it breaks the esptool?
radimkarnis
commented
1 year ago Looks like when Serial.print send a lot of data to the console, it breaks the esptool?
Yes, there may be some data left in the buffer that messes up esptool communication. I will try to reproduce this and look into it! Thank you
radimkarnis
commented
1 year ago Hi @LuisCRSousa,
I wasn't able to reproduce the issue based on your instructions. Could you please provide more info -
1) What are your settings in the Tools tab in the Arduino IDE when compiling and uploading the sketch?
2) Do you see any output from the sketch if you open the serial console?
Thank you!
LuisCRSousa
commented
1 year ago Forgot to mention that I also changed the ASCIITable arduino example baud rate from 9600 to 115200. I don't have the board with me atm so I can't test with the original speed. So maybe higher speeds are more susceptible to this bug?
My ASCIITable arduino example:
/*
ASCII table
Prints out byte values in all possible formats:
- as raw binary values
- as ASCII-encoded decimal, hex, octal, and binary values
For more on ASCII, see http://www.asciitable.com and http://en.wikipedia.org/wiki/ASCII
The circuit: No external hardware needed.
created 2006
by Nicholas Zambetti <http://www.zambetti.com>
modified 9 Apr 2012
by Tom Igoe
This example code is in the public domain.
https://www.arduino.cc/en/Tutorial/BuiltInExamples/ASCIITable
*/
void setup() {
//Initialize serial and wait for port to open:
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
// prints title with ending line break
Serial.println("ASCII Table ~ Character Map");
}
// first visible ASCIIcharacter '!' is number 33:
int thisByte = 33;
// you can also write ASCII characters in single quotes.
// for example, '!' is the same as 33, so you could also use this:
// int thisByte = '!';
void loop() {
// prints value unaltered, i.e. the raw binary version of the byte.
// The Serial Monitor interprets all bytes as ASCII, so 33, the first number,
// will show up as '!'
Serial.write(thisByte);
Serial.print(", dec: ");
// prints value as string as an ASCII-encoded decimal (base 10).
// Decimal is the default format for Serial.print() and Serial.println(),
// so no modifier is needed:
Serial.print(thisByte);
// But you can declare the modifier for decimal if you want to.
// this also works if you uncomment it:
// Serial.print(thisByte, DEC);
Serial.print(", hex: ");
// prints value as string in hexadecimal (base 16):
Serial.print(thisByte, HEX);
Serial.print(", oct: ");
// prints value as string in octal (base 8);
Serial.print(thisByte, OCT);
Serial.print(", bin: ");
// prints value as string in binary (base 2) also prints ending line break:
Serial.println(thisByte, BIN);
// if printed last visible character '~' or 126, stop:
// if (thisByte == 126) { // you could also use if (thisByte == '~') {
// // This loop loops forever and does nothing
// while (true) {
// continue;
// }
// }
// go on to the next character
thisByte++;
}@LuisCRSousa thank you, with your additional instructions, I have reproduced the issue! At first glance, I don't know if this should be patched in esptool or the stub flasher. I will investigate more.
Operating System
windows 11
Esptool Version
All releases since 3.2
Python Version
Python 3.10.4
Chip Description
ESP32-S3
Device Description
WT32-S3-WROVER on a SC01 Plus Dev kit
Hardware Configuration
SC01 Plus Dev kit
How is Esptool Run
Windows terminal and also with Arduino IDE
Full Esptool Command Line that Was Run
python esptool.py --trace --chip auto erase_flash
Esptool Output
More Information
I manage to flash the board with Arduino IDE 2.04 (esptool.py v4.2.1) a few times.
The last successful flash was the ASCIITable example with baud rate changed to 115200 and printing continuously to infinity. The board still runs it ok. After this I can't get to flash anything or even erase the flash using any version of esptool.
Checking the log, it seems to stop when stub starts running. If I try to erase the flash using '--no-stub' the esptool gives the following message: 'A fatal error occurred: ESP32-S3 ROM does not support function erase_flash'
I also increased the loader.py timeouts (MEM_END_ROM_TIMEOUT inclusive from 0.2 up to 20) with no changes.
I'm out of ideas atm
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide