At v23 fails to boot on 512kB, fatal exception - RESOLVED

[trickedj]

Update 21st July - This issue has now been resolved, see my post at end of thread for details
--------------------------------------------------------------------------------------------------------------

I have successfully continued to use v22, v23b1 & v23b2 on 512kbyte modules with no problem using the method outlined by doughboy here viewtopic.php?f=16&t=326.

However today I have tried to load AT v23 (released yesterday) and I get an exception at boot which just loops forever. Is there a work around or is this the end of 512kbyte modules ? Anybody else have the same problem ?

espressif, please don't rule out these modules, there must be millions in use now !

Bootlog follows (I tried bootloader 1.2 & 1.3b3)

ets Jan 8 2013,rst cause:1, boot mode:(3,5)

load 0x40100000, len 816, room 16
tail 0
chksum 0x8d
load 0x3ffe8000, len 788, room 8
tail 12
chksum 0xcf
ho 0 tail 12 room 4
load 0x3ffe8314, len 288, room 12
tail 4
chksum 0xcf
csum 0xcf

2nd boot version : 1.2
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 4Mbit
jump to run user1

Fatal exception (0):
epc1=0x4010032b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x4010032b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x4010032b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):

[ESP_Faye]

Hi,

in your case, please do not burn master-device-key.bin or any other bin files in 0x3E000.

if your problem still exists, please offer the capture picture of your flash download tool.

[trickedj]

Hi,

All I tried to program was:
0x00000 boot_v1.2.bin
0x7c000 esp_init_data_default.bin
0x7e000 blank.bin
0x01000 user1.1024.new.bin

If this is not correct please let me know. I originally used the esptool.py and the modules gave the exception in my previous message, I have just tried with the 'esp flash tool' and get a slightly different result "get flash_addr error" see log and screenshot below.

I have tried two ESP-01 512kB modules with the same failure on ATv23, both work with ATv23b2 ok.
I can successfully use ATv23 on a 2mB Olimex module with the same procedure without problems.

Any help appreciated, thanks
D Tricker

ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 816, room 16
tail 0
chksum 0x8d
load 0x3ffe8000, len 788, room 8
tail 12
chksum 0xcf
ho 0 tail 12 room 4
load 0x3ffe8314, len 288, room 12
tail 4
chksum 0xcf
csum 0xcf

2nd boot version : 1.2
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 4Mbit
jump to run user1

get flash_addr error!
user code done

Screenshot

EspFlashTool.jpg (62.35 KiB) Viewed 22805 times

[doughboy]

try 0x00000 boot_v1.2 (or 1.3)
0x01000 user1.1024.new.bin
0x7e000 blank.bin

make sure to select 8mbit even if your module is 4mbit.

I found out if you select 4mbit, that setting is stored in firmware and firmware code will write to address 0x3E000, which contains firmware code.

I have not actually tried this but I'm almost certain it will work. I have since moved on to olimex module that has 16mbit flash.

[trickedj]

Hi,

I just tried the 8mbit setting and unfortunately it makes no difference

[trickedj]

I noticed there was a more upto date version of the ESP FLASH DOWNLOAD tool V 9.6.0

That now allows me to successfully boot the ESP-01 modules and i can connect to an AP the first time. HOWEVER after I reboot the module it goes into another continuous exception loop. I suspect it is because my application uses the nnn_DEF commands which write to the user data area which I believe was at around 0x3c000 which is now in the extended firmware space. Hence the code is overwritten and crashes next time it is run.

I repeated the above using the 8Mbit setting to perhaps move the user area but the outcome was similar : first boot ok, subsequent boots produced
2nd boot version : 1.2
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 8Mbit
jump to run usererror user bin flag, flag = 6
user code done



So back to my original question, given the number of 512kb modules in the market, is it possible, please, to continue to produce a 512kb bin, perhaps with limited functionality ( i would be happy to lose the CIUPDATE command ) to allow continued use of this hardware ?

Thanks

D Tricker

[doughboy]

I've never used 1.2 boot, can you try 1.3?

If you are able to get AT to respond, enter command AT+CIPSTA?
if you blanked user area, it will be all 0. if it is garbage, that means the firmware is reading the data where code is.
After you connect to your router, AT+CIPSTA? should show your ip address, gateway, etc.
If it shows garbage, then the firmware is storing the data to the same location as code.


Also, I forgot to mention, when you compile, make sure to compile to 1MB flash as well.
In theory, If firmware thinks it is running on 1MB, it should not write to code area under 512kb,

I can't say for sure if using the newer flash downloader will make any difference.

As to your question on making this work for 512kb flash. I'm sure it can be done. The only reason for needing twice the space is because of the online update, which I don't think is really useful. More like a novelty. The actual firmware code can definitely fit in 512kb space. I do not know anything about how the compiler works to modify the options to make it work in 512kb flash. Perhaps someone more knowledgeable can do this.

[doughboy]

I just tried it and it worked for me. I'm going to run my test programs to confirm .

AT+CIPSTA?

+CIPSTA:ip:"0.0.0.0"
+CIPSTA:gateway:"0.0.0.0"
+CIPSTA:netmask:"0.0.0.0"

OK
AT+CWMODE=1


OK
AT+CIPMUX=1


OK
AT+CWJAP="x","x"

WIFI CONNECTED
WIFI GOT IP

OK
AT+CIPSTA?

+CIPSTA:ip:"192.168.1.26"
+CIPSTA:gateway:"192.168.1.1"
+CIPSTA:netmask:"255.255.255.0"

OK
AT+GMR

AT version:0.23.0.0(Apr 24 2015 21:11:01)
SDK version:1.0.1
compile time:Apr 24 2015 21:19:31

OK

[doughboy]

ok, my first test program, I got garbage for server ip.
So apparently, this does not work anymore.

this is what I get on cipsta, which I know is incorrect.
+CIPSTA:ip:"108.48.114.52"
+CIPSTA:gateway:"108.48.114.1"
+CIPSTA:netmask:"255.255.255.0"

and I also now get the continuous reboot.

I'll see if there is any other way.

your option for now is, get olimex board, or you can get a 16mbit flash for cheap and replace the one on esp-01, but I think this may be too much trouble and requires some surface mount component soldering/desoldering skill.

[doughboy]

ok, I figured out what is causing the flash corruption.

if you are using 512k flash, DO NOT USE COMMAND AT+RST!!

This will trash the code area and will corrupt the firmware and result in continuous reboot.

I am able to run my test program now after I remove the call to AT+RST.