-
Notifications
You must be signed in to change notification settings - Fork 119
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
[ESP32-S2] Not able to monitor device after flashing - device not booting properly #621
Comments
Running the same thing on a normal esp-32 seems to work fine with exactly same setup. ESP32 flash logs
|
|
Hey @SergioGasquez, thanks for the quick reply! 1 - In the attempt mentioned above, I pressed Ctrl + R, waited briefly, manually reset the board using the RESET button, and then attempted to use |
I am not sure how its done in the no_std template, but the s2 is a bit special - e.g it can use usb-otg or usb-cdc-acm, but not both at the same time. So if you are flashing it and your binary doesn't setup usb-otg and your are not falling back to manually enabling usb-cdc the board just simply will not be there after it is started. |
on esp-idf-template based project you need to set usb-cdc manually to be used via a sdkconfig but not sure how that all works on the no_std site. |
@Vollbrecht Are you referring to this esp usb doc, right? I was able to make the
I am still unable to make this work with the |
I assume that not initiating the usb-cdc in some form on the no_std binary may be the problem here, though my knowledge is limited here as i am not actively using the no_std hal. Maybe someone else could tell if they implement this correctly here. |
We have an usb cdc example in esp-hal, see https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/usb_serial.rs |
After spending some time on this, I believe I've grasped the core of the issue. The USB-CDC initialization occurs in the bootloader if Moreover, the flash stub provided doesn't seem to function as expected either, likely due to the absence of USB OTG support. The example provided by @SergioGasquez seems to work for what is intended. However, it does not initialize the console itself, and I don't see any logs after reset, I still not able to see bootloader nor application logs.
It appears that |
Alright, I've decided to take a more proactive approach and have connected a USB-Serial adapter to the UART0 pins. As expected, all the console logs that were meant to be redirected to USB are present. Moreover, when I flash a C esp-idf example with USB CDC enabled, all the console logs are successfully redirected to USB. Now, here's my idea: What if I flash the bootloader generated in the C esp-idf project into my Rust esp-idf project using the esp flash --bootloader argument? I attempted this approach using the following command:
However, I couldn't get it to work as expected. The first-stage bootloader fails to the new bootloader; it simply does not print any logs in UART0 related to second stage bootloader, not creates any new USB file descriptor. Here's the output I'm getting from UART0:
Here is the output of the esp-idf C project flashed using esptool:
Here is the output of rust project flashed with the espflash bootloader:
|
@SergioGasquez Is there any special steps I need to take to compile the bootloader from esp-idf? https://github.com/esp-rs/espflash/tree/main/espflash/resources - you mentioned that it's compiled by hand |
If you are using the esp-idf-template and build a hello-world, you can find that a corresponding bootloader is build and put out inside the output directory. So your output contains 3 files. The bootloader.bin the partition-table.bin and the hello-world elf file |
|
@Vollbrecht Yup, I'm using the |
Same result as before with this command:
Output from UART0:
|
I think you should use |
I've been consistently using To address this, I believe flashing a bootloader compiled with I'm not sure whether this is an issue or not. Is it expected behavior for console output to always redirect to the serial used for flashing the device? This seems to be the default behavior of esp-idf(flashtool), if I'm not mistaken. Perhaps we could enhance the granularity of espflash arguments to enable selection of an ESP32-S2 target that utilizes USB-OTG. For that we would need a new esp32bootloader-withusb.bin and more targets to be configured, which does not sounds as good solution. |
When using
Could you verify this, please?
I am not sure if I like the idea of adding more bootloaders, which result in a more difficult maintenance and are not really useful for most users. |
I have been experiencing this issue while trying to flash the Flipper Zero Wi-Fi Module. I have been able to flash using What I would need to do is add a feature in the esp-println crate to use USB CDC and then somehow implement that. The espressif docs mention a USB CDC implementation in the ROM code. Does anyone know where I could find more information about the ROM code and the functions that might be there for USB CDC? |
I'm a little puzzled by this stance. I have three different "hobby" ESP32-S2 based dev boards (Adafruit ESP32-S2, Feather-S2 and an Adafruit MagTag) that all rely on USB CDC for their serial connection. So those boards are ergonomically hard to use since I moved up to espflash 3. (Oh, and a Lolin ESP32-S2 based board too. I think it's a D2?) |
I am currently attempting to flash my ESP-32-s2 device using the
esp-template
andespflash
tool. However, I am facing issues in getting the compiled binary to run successfully on my device. My initial problem was with resetting the device, as it was not resetting as expected compared to esptool.py. After several attempts, I discovered that setting-b no-reset
was necessary to initiate the flashing process successfully.Even after flashing, my device does not boot up or display anything. I noticed that when I manually reset the device, the serial ports disappear.
Click to expand Full logs
Click to expand esptool.py LOGS that are working
esptool.py --chip esp32s2 -p /dev/cu.usbmodem01 -b 460800 --before=no_reset --after=no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 bootloader/bootloader.bin 0x10000 salmon.bin 0x8000 partition_table/partition-table.bin
esptool.py v4.7.dev1
Serial port /dev/cu.usbmodem01
WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
Connecting...
Chip is ESP32-S2FH4 (revision v0.0)
Features: WiFi, Embedded Flash 4MB, No Embedded PSRAM, ADC and temperature sensor calibration in BLK2 of efuse V1
Crystal is 40MHz
MAC: 84:f7:03:e8:6c:5e
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00006fff...
Flash will be erased from 0x00010000 to 0x00047fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 21888 bytes to 13918...
Writing at 0x00001000... (14 %)
Writing at 0x00002526... (28 %)
Writing at 0x00003181... (42 %)
Writing at 0x00003cd1... (57 %)
Writing at 0x00004740... (71 %)
Writing at 0x0000510d... (85 %)
Writing at 0x00005c33... (100 %)
Wrote 21888 bytes (13918 compressed) at 0x00001000 in 0.4 seconds (effective 460.3 kbit/s)...
Hash of data verified.
Compressed 227296 bytes to 125420...
Writing at 0x00010000... (1 %)
Writing at 0x0001118b... (3 %)
Writing at 0x000127d3... (4 %)
Writing at 0x00014109... (6 %)
Writing at 0x00015826... (8 %)
Writing at 0x000167e3... (9 %)
Writing at 0x00017d0b... (11 %)
Writing at 0x000190ea... (12 %)
Writing at 0x0001af34... (14 %)
Writing at 0x0001ca0d... (16 %)
Writing at 0x0001e202... (17 %)
Writing at 0x00020074... (19 %)
Writing at 0x00020bf2... (20 %)
Writing at 0x0002173a... (22 %)
Writing at 0x00022163... (24 %)
Writing at 0x00022bd0... (25 %)
Writing at 0x000235c3... (27 %)
Writing at 0x0002434f... (29 %)
Writing at 0x00024da2... (30 %)
Writing at 0x00025a50... (32 %)
Writing at 0x00026520... (33 %)
Writing at 0x00027245... (35 %)
Writing at 0x00027e1b... (37 %)
Writing at 0x00028951... (38 %)
Writing at 0x000293db... (40 %)
Writing at 0x00029f7d... (41 %)
Writing at 0x0002ab38... (43 %)
Writing at 0x0002b5be... (45 %)
Writing at 0x0002c1a5... (46 %)
Writing at 0x0002cc40... (48 %)
Writing at 0x0002d68f... (50 %)
Writing at 0x0002e173... (51 %)
Writing at 0x0002ed9e... (53 %)
Writing at 0x000303de... (54 %)
Writing at 0x00031005... (56 %)
Writing at 0x00031a3f... (58 %)
Writing at 0x0003248c... (59 %)
Writing at 0x0003324c... (61 %)
Writing at 0x000345b0... (62 %)
Writing at 0x00035a77... (64 %)
Writing at 0x000376fa... (66 %)
Writing at 0x00038314... (67 %)
Writing at 0x00038e78... (69 %)
Writing at 0x00039e22... (70 %)
Writing at 0x0003a9cd... (72 %)
Writing at 0x0003b457... (74 %)
Writing at 0x0003c066... (75 %)
Writing at 0x0003cb09... (77 %)
Writing at 0x0003d6a6... (79 %)
Writing at 0x0003e256... (80 %)
Writing at 0x0003ee2d... (82 %)
Writing at 0x0003f9d6... (83 %)
Writing at 0x000404c5... (85 %)
Writing at 0x00040ffa... (87 %)
Writing at 0x00041b1d... (88 %)
Writing at 0x000426de... (90 %)
Writing at 0x000432b6... (91 %)
Writing at 0x0004439b... (93 %)
Writing at 0x000451bb... (95 %)
Writing at 0x00045b1c... (96 %)
Writing at 0x000466fb... (98 %)
Writing at 0x0004742a... (100 %)
Wrote 227296 bytes (125420 compressed) at 0x00010000 in 1.9 seconds (effective 944.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.1 seconds (effective 388.7 kbit/s)...
Hash of data verified.
Leaving...
Staying in bootloader.
Done
Os: MacOS
espflash Version: 3.0.1-dev
The text was updated successfully, but these errors were encountered: