Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unstable version without build option RELEASE because of size #1294

Closed
MaBecker opened this issue Jan 2, 2018 · 13 comments
Closed

unstable version without build option RELEASE because of size #1294

MaBecker opened this issue Jan 2, 2018 · 13 comments
Labels
ESP8266 This is only a problem on ESP8266 devices

Comments

@MaBecker
Copy link
Contributor

MaBecker commented Jan 2, 2018

building Espruino for BOARD=ESP8266_4MB without RELEASE=1 causes a endless loop after reboot

>require('ESP8266').reboot();
=undefined
>
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
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      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000
Fatal exception (3):
epc1=0x401000b8, epc2=0x00000000, epc3=0x00000000, excvaddr=0x401000df, depc=0x00000000
Fatal exception (3):
epc1=0x401000b8, epc2=0x00000000, epc3=0x00000000, excvaddr=0x401000df, depc=0x00000000

Stange, a build with BOARD=ESP8266_4MB RELEASE=1 make has no problems with reboot on the same device ....

@MaBecker MaBecker added bug ESP8266 This is only a problem on ESP8266 devices labels Jan 2, 2018
@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 3, 2018

http://0x04.net/~mwk/doc/xtensa.pdf Table 4–64. Exception Causes

3 LoadStoreErrorCause   Processor internal physical address or data error      YES
                        during load or store [Exception Option]

Check with esptool.py verify_flash .....

Verifying 0xf10 (3856) bytes @ 0x00000000 in flash against /esptools/esp_iot_sdk/sdk_20/bin/boot_v1.6.bin...
-- verify OK (digest matched)
Verifying 0x834a4 (537764) bytes @ 0x00001000 in flash against espruino_esp8266_user1.bin...
-- verify FAILED (digest mismatch)
Verifying 0x80 (128) bytes @ 0x003fc000 in flash against /esptools/esp_iot_sdk/sdk_20/bin/esp_init_data_default.bin...
-- verify OK (digest matched)
Verifying 0x1000 (4096) bytes @ 0x003fe000 in flash against /esptools/esp_iot_sdk/sdk_20/bin/blank.bin...
-- verify OK (digest matched)
Verifying 0x834a4 (537764) bytes @ 0x00101000 in flash against espruino_esp8266_user1.bin...
-- verify OK (digest matched)

Found the reason: digest mismatch for espruino_esp8266_user1.bin @ 0x00001000!?

@MaBecker MaBecker removed the bug label Jan 3, 2018
@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 3, 2018

Looks like a flash speed problem

@MaBecker MaBecker changed the title unstable version without build option RELEASE unstable version without build option RELEASE because of size Jan 3, 2018
@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 3, 2018

Tried some different builds based on Espruino master 1v95

At the end it seems to be a problem of bin file size - as far as I understand.

Any advice /suggestion?

Because during development and testing it is very helpful to have a stable version with os_prints (require('ESP8266').setLog(2); )

crashing build

make flash_erase && make clean && ESP8266_4MB=1 make flash
user1.bin uses  537364 bytes of 962560 available

working builds

#default

  make flash_erase && make clean && ESP8266_4MB=1 RELEASE=1 make flash
  user1.bin uses  509204 bytes of 962560 available

#build without 'GRAPHICS'

make flash_erase && make clean && ESP8266_4MB=1 make flash
user1.bin uses  513380 bytes of 962560 available

#build without CFLAGS += -mforce-l32

make flash_erase && make clean && ESP8266_4MB=1 make flash
user1.bin uses  501092 bytes of 962560 available

@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 5, 2018

full output of build for that crashing bin file:

make clean && ESP8266_4MB=1 make

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  3 .text         00007cdc  40100000  40100000  00003230  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .irom0.text   000784a4  40201010  40201010  0000af10  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
To disassemble: xtensa-lx106-elf-objdump -d -l -x espruino_esp8266_user1.elf
xtensa-lx106-elf-objdump -d -l -x espruino_esp8266_user1.elf >espruino_esp8266_user1.lst
  8 -rwxr-xr-x  1 markbecker  staff    2220  5 Jan 11:32 eagle.app.v6.data.bin
968 -rwxr-xr-x  1 markbecker  staff  492708  5 Jan 11:32 eagle.app.v6.irom0text.bin 
 24 -rwxr-xr-x  1 markbecker  staff   10400  5 Jan 11:32 eagle.app.v6.rodata.bin
 64 -rwxr-xr-x  1 markbecker  staff   31964  5 Jan 11:32 eagle.app.v6.text.bin
** user1.bin uses  537364 bytes of 962560 available

So this is a ticking time bomb for the RELEASE=1 build.

@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 5, 2018

Hi @gfwilliams any idea from your side?

@gfwilliams
Copy link
Member

gfwilliams commented Jan 5, 2018

Not really - it's pretty common not to be able to build for boards without RELEASE=1 - when I build with debug info I tend to just disable libraries I'm not using in the Python board file

Just to add: if the binary is too large then the build process should really pick that up and fail - it does for other boards. It can be a pain to handle in the linker so there's a script called check_size.sh

@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 5, 2018

just disable libraries I'm not using in the Python board file

That is my workaround as well.

Using flash map 6 (4MB:1024/1024) allows to use larger files to flash ESP_FLASH_MAX=962560

4mb_1024 1024

so check.sh is not complaining

PASS - size of 537828 is under 962560 bytes

So there must be something that is missing....

@netico14
Copy link

netico14 commented Jan 7, 2018

hello, I have a problem with my esp-01 or esp8266-01, sorry write here but i dont understand github, I was programming with arduino ide and it worked fine, but I could not receive a data from socket.io so I liked espruino but I can not connect, does not recognize my esp-01, I have already tried with another one that I have but it does not work, delete the firmware, update it with the files of the updated espruino page, probe with the old firmware but nothing, I made the update by esptool and by nodemcu firmware programmer but nothing works for me, I ask for your help, thank you very much

@MaBecker
Copy link
Contributor Author

MaBecker commented Jan 7, 2018

Hi @netico14,

please post you ESP - Espruino problem here.

@wilberforce
Copy link
Member

@MaBecker
Isn't new this related to the flashing and needing the flash_size 4MB-c1 To select the 1024/1024 map?

@MaBecker
Copy link
Contributor Author

When ESP8266_4MB=1 is set than make flash is using flash_size 4MB-c1

The question is : Why can't a build use more than 512 KB whe using 4MB-c1like shown in picture above?

@wilberforce
Copy link
Member

Perhaps it is the linking script - the .ld file - the existing might have a 512K limitation.

@MaBecker
Copy link
Contributor Author

https://github.com/espruino/Espruino/blob/master/targets/esp8266/eagle.app.v6.new.2048.ld#L3-L9

MEMORY
{
dport0_0_seg : org = 0x3FF00000, len = 0x10
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
iram1_0_seg : org = 0x40100000, len = 0x8000
irom0_0_seg : org = 0x40201010, len = 0xE0000
}

gfwilliams added a commit that referenced this issue May 10, 2018
rearange rf_cal_sector (fix #1294)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ESP8266 This is only a problem on ESP8266 devices
Projects
None yet
Development

No branches or pull requests

4 participants