Hi,
I have several questions about ESP32 ROM and firmware.
1. I don't understand well the meaning of firmware. Is it the software located in the internal ROM? Or is it located in the external flash.
2. If it is located in the internal ROM then I need firmware sources to make changes and then update image in the ROM. How can I find them?
3. Can I update the firmware using Arduino?
Thank you very much.
ESP32 ROM update
Re: ESP32 ROM update
Have a read at the following Wikipedia article on Firmware.
https://en.wikipedia.org/wiki/Firmware
Following that notion, the ESP-IDF SDK plus your own application code ... is what we would consider "firmware". The firmware is written into flash memory and is available when your ESP32 boots.
While the ESP32 does indeed have a ROM built in, for our purposes, we can ignore it. It is created by Espressif and provide the core functions necessary to get the ESP32 started when it is powered on. When you write applications ... typically you will write them in C and then link them with either the ESP-IDF or the Arduino libraries. This results in a binary file which you write into flash memory (using the esptool tool or some other tools such as the Arduino IDE). When the ESP32 boots, it will load your previously saved (flashed) application and run it.
https://en.wikipedia.org/wiki/Firmware
Following that notion, the ESP-IDF SDK plus your own application code ... is what we would consider "firmware". The firmware is written into flash memory and is available when your ESP32 boots.
While the ESP32 does indeed have a ROM built in, for our purposes, we can ignore it. It is created by Espressif and provide the core functions necessary to get the ESP32 started when it is powered on. When you write applications ... typically you will write them in C and then link them with either the ESP-IDF or the Arduino libraries. This results in a binary file which you write into flash memory (using the esptool tool or some other tools such as the Arduino IDE). When the ESP32 boots, it will load your previously saved (flashed) application and run it.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
-
- Posts: 7
- Joined: Thu Jan 05, 2017 9:36 am
Re: ESP32 ROM update
Kolban,
Thank you very much for your response.
Now it is more clear for me. So it is not possible to reprogram ROM, which is good.
Could you please let me know where are located WiFi and Bluetooth stacks? In the ROM or it comes with the firmware?
If I program ESP32 module via Arduino environment what will happen with existing firmware? The flash will be erased and loaded with the new image.
Bests Regards.
Thank you very much for your response.
Now it is more clear for me. So it is not possible to reprogram ROM, which is good.
Could you please let me know where are located WiFi and Bluetooth stacks? In the ROM or it comes with the firmware?
If I program ESP32 module via Arduino environment what will happen with existing firmware? The flash will be erased and loaded with the new image.
Bests Regards.
-
- Posts: 9772
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 ROM update
Small nitpick: The ROM isn't entirely unused when the application is booted. There are some useful C functions located in ROM; esp-idf links to them if possible because executing them is very fast and does not put pressure on the flash cache. For example, if you select nano-printf, that is entirely located in ROM.
The lower level of BT is located in ROM; it eats up a major part of it, actually. For WiFi, I think only the PHY code is located in ROM.,
The lower level of BT is located in ROM; it eats up a major part of it, actually. For WiFi, I think only the PHY code is located in ROM.,
Re: ESP32 ROM update
t_bostanjyan,
When you write C code (either inside or outside of the Arduino IDE) you then link-edit it with your local compiled ESP-IDF SDK which is primarily supplied in source (and some libraries). All of this is "statically" linked together so you end up with a binary file that contains a mixture of your written code and ESP-IDF code. When you flash that to the ESP32 ... that "binary file" is stored in flash memory (I'm being loose here). When your ESP32 boots, control is eventually passed to a program called the "Bootloader". Interestingly you also flash this into your ESP32 but by and large, most folks don't "touch that" and flash it as is. The Bootloader then passes control to your compiled application and it is running.
An important thing to note is that when you flash an ESP32 ... you don't normally flash ALL of the ESP32s 4MBytes of flash. Instead, you may notice that the esptool names a file and where in flash to load it. That file will then be saved in flash at that location. Space below and after the save is left as it was. The interesting thing to note about that ... is that you can actually have multiple "copies" of programs in flash as long as they don't overlap with each other and there is enough space to hold them both (all). This is the principle of "OTA" (Over the air). Which is the notion that if you are loading a new version of a program, it can load into a different area of flash and if there is a communication failure, the original program is untouched and your ESP32 isn't "bricked".
This is more subtle/advanced stuff. For simple folks like me (and maybe yourself) ... every time we flash a change to our applications, it replaces the version that was previously there.
When you write C code (either inside or outside of the Arduino IDE) you then link-edit it with your local compiled ESP-IDF SDK which is primarily supplied in source (and some libraries). All of this is "statically" linked together so you end up with a binary file that contains a mixture of your written code and ESP-IDF code. When you flash that to the ESP32 ... that "binary file" is stored in flash memory (I'm being loose here). When your ESP32 boots, control is eventually passed to a program called the "Bootloader". Interestingly you also flash this into your ESP32 but by and large, most folks don't "touch that" and flash it as is. The Bootloader then passes control to your compiled application and it is running.
An important thing to note is that when you flash an ESP32 ... you don't normally flash ALL of the ESP32s 4MBytes of flash. Instead, you may notice that the esptool names a file and where in flash to load it. That file will then be saved in flash at that location. Space below and after the save is left as it was. The interesting thing to note about that ... is that you can actually have multiple "copies" of programs in flash as long as they don't overlap with each other and there is enough space to hold them both (all). This is the principle of "OTA" (Over the air). Which is the notion that if you are loading a new version of a program, it can load into a different area of flash and if there is a communication failure, the original program is untouched and your ESP32 isn't "bricked".
This is more subtle/advanced stuff. For simple folks like me (and maybe yourself) ... every time we flash a change to our applications, it replaces the version that was previously there.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: ESP32 ROM update
Dear ESP32 team,
I also new to ESP32. I bought 2 Wrover KIT and I faced the issue with IO13.
My application will configure the VSPI pin as following:
#define SPI_HOST VSPI_HOST
#define GPIO_MOSI 13 //13 //19 //VSPIQ
#define GPIO_MISO 12 //23 //VSPID
#define GPIO_SCLK 14 //18 //VSPICLK
#define GPIO_CS 15 //25//04 //VSPI_CS0 //ERROR: Connect with PIN CS by driver
#define GPIO_PDN 19//21
#define GPIO_INT 22
The problem is that one Wrover KIT board works fine with that configuration, however, another KIT got reboot recurrently. After debugging, I found that the KIT will reboot if it invokes the function gpio_matrix_out() to set MOSI pin.
I learnt that gpio_matrix_out() is located in ESP32 ROM so is there any way to copy ROM from one Wrover KIT then reflash it to other ?
Thanks and regards,
CDQ
I also new to ESP32. I bought 2 Wrover KIT and I faced the issue with IO13.
My application will configure the VSPI pin as following:
#define SPI_HOST VSPI_HOST
#define GPIO_MOSI 13 //13 //19 //VSPIQ
#define GPIO_MISO 12 //23 //VSPID
#define GPIO_SCLK 14 //18 //VSPICLK
#define GPIO_CS 15 //25//04 //VSPI_CS0 //ERROR: Connect with PIN CS by driver
#define GPIO_PDN 19//21
#define GPIO_INT 22
The problem is that one Wrover KIT board works fine with that configuration, however, another KIT got reboot recurrently. After debugging, I found that the KIT will reboot if it invokes the function gpio_matrix_out() to set MOSI pin.
I learnt that gpio_matrix_out() is located in ESP32 ROM so is there any way to copy ROM from one Wrover KIT then reflash it to other ?
Thanks and regards,
CDQ
-
- Posts: 9772
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 ROM update
The ROM is very much fixed; unless you decap the chip and rent time on a FIB workstation, there's no way you're going to reflash this. The good thing is that this also means that there's absolutely zero chance the two chips have a differing ROM. What I do suspect is that there's a short between one of the pins you're trying to configure as an output and one of the GPIOs the flash is connected to; from experience, my best guess would be that IO13 is shorted to SD2. Can you see if that's the case?
Re: ESP32 ROM update
Thanks for your suggestion. However, this is not my case. I tried to unplug any jumpers or connection and just monitor (make monitor) and the Wrover KIT reboot when it call gpio_matrix_out() to set MOSI pin. It looks like a segfault in ROM code then reboot is triggered.
-
- Posts: 9772
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 ROM update
Can you still check if there is a short on the PCB itself like this? I have heard that a few older boards sometimes have this, and we have since modified our production process to eliminate this, but you may have one of the affected boards.
Who is online
Users browsing this forum: No registered users and 78 guests