ESP8266 Developer Zone

Re: bootv1.7.bin BUG

2017-11-13T18:37:07+08:00

Thanks for the replies and tips.

I know I'm running user2.bin, because system states (on boot): jump to run user2 @ 81000
I'm sure the FOTA functions are erasing / writing user1.bin - when the garbage on the UART appear.
To make it work again I need to flash user1.bin - however the sytem still states (on boot): jump to run user2 @ 81000
So it seems I can´t let system_upgrade_start flash whatever it wants on user1, because it might destroy booting user2 (current firmware booting). If I completely erase the user1.bin area (by UART), it also works, booting user2.
So I'm now sure system_upgrade_start can flash something wrong to user1.bin area that prevents system bootv.1.7.bin to run user2 (that has a valid firmware loaded). I don't understand is why bootv.1.7.bin has to check user1.bin area, when the flag is set to run user2.bin.
Maybe someone from EspressIf can reply.

Statistics: Posted by skywave — Mon Nov 13, 2017 6:37 pm

Re: bootv1.7.bin BUG

2017-11-13T17:40:28+08:00

I have experimented a lot and I found out it is best to rely on system_get_userbin_addr() and not system_upgrade_userbin_check(). No problems since then.

Before that, I had cases when system_upgrade_userbin_check() was 1 (== bin2) and system_get_userbin_addr() was 0x1000... I flashed starting from 0x1000 and the whole thing crashed under my nose.

Statistics: Posted by blubb — Mon Nov 13, 2017 5:40 pm

Re: bootv1.7.bin BUG

2017-11-13T10:23:21+08:00

Maybe there is something wrong with your FOTA function.
It seems to always erase the user2.bin, when you run user1.bin to erase and update the user2.bin, it works fine; but when you run user2.bin, it is still erasing the user2.bin so the system crashed, because you erased the running firmware.

Statistics: Posted by Her Mary — Mon Nov 13, 2017 10:23 am

bootv1.7.bin BUG

2017-11-10T19:55:59+08:00

Hi There,

I have been testing FOTA upgrade process with custom server and ESP8285.
When running user1.bin -> the system OTA downloads user2.bin and reboots -> no problem.
However when running user2.bin -> after calling system_upgrade_start -> we receive the HEAD request on the server and the GET (download) -> after awhile (a few seconds) -> UART interface (used for debug) starts to send garbage.
When I manually reset the ESP8285 it jumps to user2.bin but throws a fatal exception epc1=0x40201dd4 (all others epc=0x00000000).

The only way to solve the boot problem is to flash (UART download) a valid user1.bin.
After manually flashing user1.bin the system runs (not the user1.bin just flashed) but user2.bin.
Despite the system is running (user2.bin) somehow what is saved on user1.bin can crash the system - what is odd.
Where does the system saves info about which user.bin to run on startup?
This really seems like a bug on bootv1.7.bin

Statistics: Posted by skywave — Fri Nov 10, 2017 7:55 pm