So you're a Noob? Post your questions here until you graduate! Don't be shy.

User avatar
By NMoaddeli
#61412 Hi Gents,

I am new to the world of ESP8266,so excuse me if you think my questions are silly questions.

I have set up my open-sdk and compiled blinky project without any error, however the program doesn't work; could someone please clarify followings. (please assume that I am intended to use NONOS SDK - I have attached the code for your reference)

1) The compiler generates two files blinky-0x10000.bin & blinky-0x00000.bin, are these the only files which should be downloaded into flash? what about other files which have been mentioned in the espressif getting started guide (i.e. eagle.flash.bin,eagle.irom0text.bin,esp_init_data_default.bin and blank.bin)
if these files need to be uploaded, could some tells me which addresses? (eagle.flash.bin & blinky-0x00000.bin seems to have same address!!!???)

2) What is the best way to debug the program in this situation?




appreciate your time

Cheers,
Nima
You do not have the required permissions to view the files attached to this post.
User avatar
By m-a-n-j-u
#62337 Sorry I'm rather late in replying and perhaps you may have already found a solution to this problem. And this post may seem rather verbose, but it is with the intention that it may help others who may face the same problem.

Short answer: You need to write esp_init_data_default.bin to the correct location in SPI flash memory. The <location> is different according to flash memory size. Look for the flash memory mapping information inside "Getting Started Guide - ESP8266". As of this writing, it can be found here:
https://espressif.com/en/support/explore/get-started/esp8266/getting-started-guide#3_2

If you are using esptool.py, use a command like this:
Code: Select allesptool.py --port /dev/ttyUSBx write_flash <location> <path>/esp_init_data_default.bin

Espressif has specified that esp_init_data_default.bin is compulsary, but has not clearly specified the criteria or reasons. So most developers are likely to miss it or misunderstand it. Without this, it appears that the ROM bootloader does not proceed to launch the user programs.

Long answer: I was struggling with this problem for the last two days myself. After generating blinky-0x00000.bin and blinky-0x10000.bin using ESP8266_NONOS_SDK and writing them to SPI flash using esptool.py, my ESP-12F module kept rebooting. I was viewing its serial output using PuTTY configured at 74880 baud, expecting to see at least some ROM bootloader messages, but it was printing only garbage.

After wasting a lot of time debugging this, I started trying out some examples using the Arduino IDE and ESP8266 Community package. I erased the flash memory:
Code: Select allesptool.py --port /dev/ttyUSBx erase_flash

And then used the Arduino IDE to build and write an example program into the ESP-12F module's SPI flash memory. The example program worked just fine.

Then I started comparing the build and flash writing commands that Arduino environment uses against what I was using with blinky and ESP8266_NONOS_SDK. Nothing seemed unusual, but blinky generated by ESP8266_NONOS_SDK was still not working. Then I stumbled upon this post by user morcillo on stackoverflow:
http://stackoverflow.com/questions/39196129

I also found that ROM bootloader messages were appearing as expected when observing the blinky example using Arduino IDE's Serial Monitor configured at 74880 baud. But PuTTY was displaying garbage for the same case. Duh! If only I could have figured this out earlier!

Each time before it rebooted, the following message appeared in Serial Monitor:
Code: Select allrf_cal[0] !=0x05,is 0xFF

Now it started becoming obvious that esp_init_data_default.bin was required to be written into SPI flash memory. So once I did that, blinky worked fine!

Then I went back and reviewed the Arduino environment. It was not explicitly writing esp_init_data_default.bin; there is not even a file of that sort inside the ESP8266 Community package. It uses a different esptool and a different linkscript (eagle.flash.512k64.ld). It also specifies "-Wl,-wrap,system_restart_local -Wl,-wrap,register_chipv6_phy" to the linker. I don't know if any of these has something to do with why examples built and written by Arduino environment work fine without esp_init_data_default.bin, though we start off with a fully erased flash memory. Looking back, I think the Arduino environment had misled me into thinking that esp_init_data_default.bin was not required.

To wrap up, here is my understanding about the flash memory map (for non-FOTA case). I have mentioned the alternatives under each flash memory location:

Flash address 0x00000: bootloader
blinky-0x00000.bin --> Bootloader written by Cesanta. It is generated by esptool.py using a dump inside itself. This is the one we will use.
eagle.flash.bin --> Bootloader supplied by Espressif. I don't know if it can launch user programs generated by ESP8266_NONOS_SDK / esp-open-sdk.
eboot --> Bootloader used by Arduino environment. It first generates eboot.elf and merges it with the user program to generate a single binary file to be written into address 0x00000.

Flash address 0x10000: user program (this location is specificied by newer linkscript "eagle.app.v6.ld")
eagle.irom0text.bin --> Default user program supplied by Espressif. I'm not sure what goes on inside it. Perhaps it is the AT-command firmware?
blinky-0x10000.bin --> Example user program that we have generated using ESP8266_NONOS_SDK / esp-open-sdk.

Flash address X (0x3FC000 in case of ESP-12F with 32 Mbit / 4 MiB flash memory): factory configuration data
esp_init_data_default.bin --> Default configuration data. Perhaps it includes something that helps RF calibration as well?

I'm not writing blank.bin that is supplied inside ESP8266_NONOS_SDK, since I'm erasing the entire flash memory beforehand. I'm not sure if it is still important to write it though.

I'm finding it difficult to answer your other question about the best way to debug this situation. Such a situation would not arise if Espressif had used a standard baudrate in their ROM bootloader and had less cryptic log messages. This could have reduced a lot of frustration and wasted time for thousands of developers. I guess community knowledge would be your best support in such situations.