2 separate ESP32 S3 beta 3 modules are giving MAC ID as MAC: 00:00:00:00:00:00
Posted: Thu Nov 25, 2021 4:53 am
I am facing a problem with getting output for a sample code(helloworld) that we were able to upload to ESP32 S3.
I am using the following configurations
Windows 10
Visual Studio Code Version 1.62.3 with ESPIDF Extension
Python version 3.8
ESP-IDF Version (4.3.1 latest) - supports ESPS3Beta3 (Which is ours)
Board Version: ESP32 S3 WROOM 1 E2 N8R2
We put the ESP32S3 in boot mode by pulling down GPIO0 and GPIO46 to GND, and was able to successfully flash the code. But the MAC address for this is MAC: 00:00:00:00:00:00.
We have tested yet another ESP32 S3 on a new board and the same No MAC Address issue is there. But it is flashing the code. The following is the log of code upload:
PS C:\Users\acer\Desktop\esp-ex\hello_world\hello_world> C:\Users\acer.espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe C:\Users\acer\esp\esp-idf\components\esptool_py\esptool\esptool.py --no-stub -p COM5 -b 115200 --before default_reset --after hard_reset --chip esp32s3beta3 write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 build/hello-world.bin 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin
esptool.py v3.1-dev
Serial port COM5
Connecting....
Chip is ESP32-S3(beta3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00010000 to 0x00037fff...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Erasing flash...
Took 1.20s to erase flash block
Wrote 162816 bytes at 0x00010000 in 16.5 seconds (78.9 kbit/s)...
Hash of data verified.
Erasing flash...
Took 0.20s to erase flash block
Wrote 19456 bytes at 0x00000000 in 2.0 seconds (78.5 kbit/s)...
Hash of data verified.
Erasing flash...
Took 0.05s to erase flash block
Wrote 3072 bytes at 0x00008000 in 0.3 seconds (81.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin.
As you can see Even Though the MAC Address issue is there for 2 separate boards, we were able to flash the code completely,
Now coming to the second issue. When we monitor the uploaded code on both the ESP32 S3s, the following reset error is coming as following:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0xa (SPI_FAST_FLASH_BOOT)
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xa (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xa (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
But we have double checked the target device and it is set to the correct chip that we have. Because unless it is not set to the correct chip we won't be even able to upload the code in the first place. We have checked eFuse issues and that also didnt help us to solve the issue.
Any help would be appreciated.
Thank You.
I am using the following configurations
Windows 10
Visual Studio Code Version 1.62.3 with ESPIDF Extension
Python version 3.8
ESP-IDF Version (4.3.1 latest) - supports ESPS3Beta3 (Which is ours)
Board Version: ESP32 S3 WROOM 1 E2 N8R2
We put the ESP32S3 in boot mode by pulling down GPIO0 and GPIO46 to GND, and was able to successfully flash the code. But the MAC address for this is MAC: 00:00:00:00:00:00.
We have tested yet another ESP32 S3 on a new board and the same No MAC Address issue is there. But it is flashing the code. The following is the log of code upload:
PS C:\Users\acer\Desktop\esp-ex\hello_world\hello_world> C:\Users\acer.espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe C:\Users\acer\esp\esp-idf\components\esptool_py\esptool\esptool.py --no-stub -p COM5 -b 115200 --before default_reset --after hard_reset --chip esp32s3beta3 write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 build/hello-world.bin 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin
esptool.py v3.1-dev
Serial port COM5
Connecting....
Chip is ESP32-S3(beta3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00010000 to 0x00037fff...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Erasing flash...
Took 1.20s to erase flash block
Wrote 162816 bytes at 0x00010000 in 16.5 seconds (78.9 kbit/s)...
Hash of data verified.
Erasing flash...
Took 0.20s to erase flash block
Wrote 19456 bytes at 0x00000000 in 2.0 seconds (78.5 kbit/s)...
Hash of data verified.
Erasing flash...
Took 0.05s to erase flash block
Wrote 3072 bytes at 0x00008000 in 0.3 seconds (81.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin.
As you can see Even Though the MAC Address issue is there for 2 separate boards, we were able to flash the code completely,
Now coming to the second issue. When we monitor the uploaded code on both the ESP32 S3s, the following reset error is coming as following:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0xa (SPI_FAST_FLASH_BOOT)
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xa (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xa (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
Invalid chip id. Expected 9 read 4. Bootloader for wrong chip?
ets_main.c 329
But we have double checked the target device and it is set to the correct chip that we have. Because unless it is not set to the correct chip we won't be even able to upload the code in the first place. We have checked eFuse issues and that also didnt help us to solve the issue.
Any help would be appreciated.
Thank You.