dump() causes reboot if E.setBootCode exists

[MaBecker]

using a Flash map 512KB:256/256, manuf 0xe0 chip 0x4016

E.setBootCode("console.log('Hi......');",true);
Erasing Flash.....
Writing...
Compressed 27200 bytes to 33
Checking...
Done!
=undefined

>require('ESP8266').reboot();
=undefined
>
 ets Jan  8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
  SPI Speed      : 40MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 4Mbit(256KB+256KB)
jump to run user1 @ 1000
�â�ì��nì�r�òn|ìl�ìl`��âr�l�þLoading 33 bytes from flash...
Hi......

dump();
// Code saved with E.setBootCode
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2408, room 16
....

[wilberforce]

I think this could be related to bytes being accessed from flash, when a 4 byte word read is required.

We have similar code to pull a byte from a double word - just need to find our where the call is failing....

Or the rom offset needs to be added onto the flas address read...

[gfwilliams]

If it's an unaligned read, it might be a good reason to add the ESP8266 aligned read compiler flag mentioned at #697 (comment) and see if that fixes it?

[MaBecker]

Yes - it is a unaligned read. Used -mforce-l32

>dump();
// Code saved with E.setBootCode
console.log('Hi......');
=undefined

But this flag blows up the code size..... had to remove crypto to fit on flash :-(

[wilberforce]

@MaBecker
Interested to know what the increase in code size is?

Perhaps there are other compiler optimise flags that can reduce the code size?

For the esp32 idf there is an option to do a core dump on the uart output - you can then take this and using the .elf file, see where the crash occurred - if there is a similar thing for the esp8266 it would help you narrow this fault down...

[MaBecker]

@gfwilliams any hints to change the coding to work without -mforce-l32 for ESP8266?

[gfwilliams]

Find out where it's crashing (is there a way of finding out the instruction's address?), and change the read to one of the macros in jsutils.h

However it'd be a mile better if someone would try and help me out with the -mforce-l32 code rather than adding yet another hack. I've done quite a bit of work in that branch, and realistically it's just a matter of trying to find out what's needed in terms of compiler flags to force read only data back into flash now (but just not the few symbols that are needed at boot time before flash is properly initialised).

... all that does already seem to have been done by other people as well: https://github.com/SuperHouse/esp-open-rtos/blob/master/ld/program.ld

[gfwilliams]

mforce-l32 stuff here: #697

You could potentially just disable os_printf, enable -mforce-l32 and I think you'd be fine code-size wise.

[opichals]

Reading this I was wondering whether the SDK 2.1 update (#1207) could help with the flash size. @MaBecker?

[MaBecker]

@opichals, SDK 2.1 is no help to reduce the flash size for BOARD=ESP8266_BOARD

2.0: user1.bin uses 453236 bytes of 479232 available

2.1: user1.bin uses 455876 bytes of 479232 available

[MaBecker]

This can be close because there is no more reboot nice Storage module is implemented.