ESP8266 Community Forum

- Mon Dec 15, 2014 8:56 am #4841 I'm trying to OTA update my custom FW into SPI Flash from web server (HTTP).

In OTA enabled SPI Flash memory map ( https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map ) there're 4 slots:
- User application, slot 1
- SDK libraries, slot 1
- User application, slot 2
- SDK libraries, slot 2

The questions are:
1. How bootloader boot.bin knows which slot (1 or 2) it should load & run during the boot ?
2. When user application runs - how it may know from which slot it runs? (for example, to download OTA upgrade code to another slot)
3. Maybe for custom application it's not necessary to use slots, but just download OTA upgrade data and rewrite it directly to SPI Flash? is it possible? (my suggestion: if app runs from RAM, then it may rewrite itself in SPI Flash with a new code)

Did anybody try to implement custom FW upgrades (User app + SDK libraries in SPI Flash) using Over-The-Air approach? (from custom web server, for example)

- Mon Dec 15, 2014 2:21 pm #4864 The Espressif cloud update function is really simple; By using different linker scripts, the linker builds two versions of app+libs (user1.bin and user2.bin) to be run from 0x01000 and 0x41000 respectively. When cloud updating, the user app+lib set not currently running will be downloaded and updated. When done, a switch in flash will be set to tell an additional "boot loader" placed at 0x00000 which set to run when booting.

I made OTA updates work by modifying the AT cloud update function to pick the firmware from any local server. I then made an ASPX script to serve out the firmware files from IIS, se this thread: http://www.esp8266.com/viewtopic.php?f=9&t=620

/Bananis

- Mon Dec 15, 2014 3:31 pm #4868 Thanks a lot, Bananis!
Your post regarding "AT firmware" was very helpful for me!

But I have another custom firmware based on very basic "hello world" firmware where I added some code for wifi connection and process short commands sent over UDP from nodejs SW on my PC, i.e. UDP client+server both on ESP8266 and PC.
And the linker produces two binaries at /firmware dir: 0x00000.bin (user app) and 0x40000.bin (SDK libraries), which are flashed by the following command line:

Code: Select allC:\Python27\python.exe c:\Espressif\utils\esptool.py -p COM2 write_flash 0x00000 firmware/0x00000.bin 0x40000 firmware/0x40000.bin

(I'm working under Windows 7 x64)
So, I suspect that the firmware that the linker produces is for "without OTA updates" memory layout.

Now when I get your (right) Makefile that produces FW for memory layout "with OTA updates", I should do the following:
1. Add a some code in my FW for handle update command via UDP (my FW use UDP), i.e. copy&paste a code of "AT+CIPUPDATE:" and correct it according my FW.
2. Flash FW with "make flash" command.
3. Run webseerver and place User1.bin and User2.bin at server's root. Then issue custom update command via WiFi.
Are the steps above correct or I forgot something?...

Is User1.bin a some concatenation of 0x01000.bin and 0x11000.bin ?

Also files User1.bin and User2.bin differs (I use "fc" under windows for compare them) - is it correct?

And also it's still mystery for me which memory slot (1 or 2) boot.bin decides to load first during boot process and _how_ it decides which one to load first...

Thanks!!!
/rekod

- Mon Dec 15, 2014 5:55 pm #4884 Your'e right about the 0x00000.bin and 0x40000.bin not being linked for OTA update. The 4 other bins made by my makefile are also combined in to the user1.bin and user2.bin if the makefile can find and run the gen_flashbin.py tool from the SDK. These are used by the espressif cloud update functions in the AT code. I would think the easiest way to implement OTA in your case would be to just copy the relevant code from the AT example as you say. It uses the sdk functions for cloud update and it seems they take care of the boot selection process. I haven't looked into that part in detail however. Just make sure to put the extra boot loader boot_v1.1.bin from the AT example, on address 0x00000.

A better way would be as you say to instead run the downloader from RAM or even to put it in the extra boot loader, but it is probably more complicated to make it work. It might be worth a try as it would be a cleaner solution.

The other steps seems right. If you use the AT code with no modifications, you'll need an aspx script on the server to hand the right file to the device. See my other posts in the cloud update thread for that and the server directory structure.

/Bananis