using more program space with 4m flash?

[tius2000]

Please excuse if this is a stupid or frequently asked question - I'm new to both SmingRTOS and GitHub :-)

First of all many thanks to everyone who contributed to SmingRTOS!

I'm using UDK 1.0 beta on windows (should be ESP8266_RTOS_SDK 1.40). Everything I tried seems to work fine after changing some sdk paths in Makefile-project.mk. However, after enabling WPS I soon ran out of program memory:

ld.exe: region `irom0_0_seg' overflowed by ... bytes

SmingRTOS seems to use the larger flash memory of 4M devices for SPIFFS only. So I tried to change eagle.app.v6.hr.ld:

irom0_0_seg : org = 0x4020A000, len = 0xF0000

This way I was able to compile run a simple test program using WPS. However, for bigger programs the EPS8266 now crashes on boot-up, like the the flash memory is corrupted somehow.

Is there a way to configure SmingRTOS to use more flash memory for program space? It would be great if one could choose between different common flash memory layouts ...

Thanks for any help!

[hreintke]

@tius2000 :
Yes, would be good to choose between memory layouts. Did some promising experiments with awk but was unable to integrate that within the makefiles. If you can help with that would be great.

On your issue. : Not clear what happens.

SmingRTOS seems to use the larger flash memory of 4M devices for SPIFFS

Especially in the irom0_0_seg the length value is not for 4M devices.
Increasing it to len = 0xF000 configures it for the 4M devices.
Be aware that the maximum program space is 1M regardless of the actual size of the flash.
The other (max) 3M can be used for spiffs and.or other boot sections

-> What is the SPI size of the esp you are using ?

You are mentioning a crash on boot-up. There can be multiple reasons for issues on that.
Without the error messages that shows up at that moment, it is not possible to have a idea on the cause.

[tius2000]

@hreintke: thank you for the fast feedback!

Did some promising experiments with awk but was unable to integrate that within the makefiles.

Unfortunately do not have experience with awk. As a start some comment or a conditionals statement within the makefile might be of help already ...

Be aware that the maximum program space is 1M regardless of the actual size of the flash.

Thank you for the hint, I did not realize that!

What is the SPI size of the esp you are using?

SPI size is 4M. I get the following messages during linking and startup:

LD out/build/app.out

#Memory / Section info:
------------------------------------------------------------------------------
   Section|                   Description| Start (hex)|   End (hex)|Used space
------------------------------------------------------------------------------
      data|        Initialized Data (RAM)|    3FFE8000|    3FFE83E4|     996
    rodata|           ReadOnly Data (RAM)|    3FFE83F0|    3FFEAFD0|   11232
       bss|      Uninitialized Data (RAM)|    3FFEAFD0|    3FFF3278|   33448
      text|            Cached Code (IRAM)|    40100000|    4010724F|   29263
irom0_text|           Uncached Code (SPI)|    4020A000|    40262AA6|  363174
Total Used RAM : 45676
Free RAM : 36244
Free IRam : 3523

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 29264, room 16
tail 0
chksum 0xc1
load 0x3ffe8000, len 996, room 8
tail 12
chksum 0x5f
ho 0 tail 12 room 4
load 0x3ffe83f0, len 11232, room 12
tail 4
chksum 0xf0
csum 0xf0
csum err
ets_main.c

It looks to me like a checksum error caused by wrong linker settings. After reducing the code size a bit (~700 bytes) everything works fine.

[hreintke]

@tius2000 :
It is a known issue which is wrong errormessage for the situation that :

  iram1_0_seg :                         org = 0x40100000, len = 0x9000
  irom0_0_seg :                         org = 0x4020A000, len = 0x52000

The iram1_0_seg is to small.
You can try :

  iram1_0_seg :                         org = 0x40100000, len = 0xA000
  irom0_0_seg :                         org = 0x4020B000, len = 0x52000

[tius2000]

Unfortunately this did not help :-(

    iram1_0_seg :                           org = 0x40100000, len = 0xA000
    irom0_0_seg :                           org = 0x4020B000, len = 0x52000

resulted in

LD out/build/app.out
... ld.exe: out/build/app.out section `.irom0.text' will not fit in region `irom0_0_seg'

changing it to

    iram1_0_seg :                           org = 0x40100000, len = 0xA000
    irom0_0_seg :                           org = 0x4020B000, len = 0xE0000

resulted in

LD out/build/app.out

#Memory / Section info:
------------------------------------------------------------------------------
   Section|                   Description| Start (hex)|   End (hex)|Used space
------------------------------------------------------------------------------
      data|        Initialized Data (RAM)|    3FFE8000|    3FFE83EC|    1004
    rodata|           ReadOnly Data (RAM)|    3FFE83F0|    3FFEAFD0|   11232
       bss|      Uninitialized Data (RAM)|    3FFEAFD0|    3FFF3278|   33448
      text|            Cached Code (IRAM)|    40100000|    4010724F|   29263
irom0_text|           Uncached Code (SPI)|    4020B000|    40263B0E|  363278
Total Used RAM : 45684
Free RAM : 36236
Free IRam : 3523
------------------------------------------------------------------------------

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 29264, room 16
tail 0
chksum 0xbe
load 0x3ffe8000, len 1004, room 8
tail 4
chksum 0x7b
load 0x3ffe83f0, len 11232, room 4
tail 12
chksum 0xf3
csum 0xf3
csum err
ets_main.c

[hreintke]

@tius2000 :
I think you really hit the RAM boundary. Then the only option is to move functions from RAM to flash.

At first : The beta UDK is using an updated compiler. You can try using the previous one and see if it solves your issue.

[tius2000]

@hreintke :

At first : The beta UDK is using an updated compiler. You can try using the previous one and see if it solves your issue

• UDK 2.09 compiler + RTOS_SDK_140: same sizes, same boot error
• UDK 2.09 compiler + RTOS_SDK_130: sizes a bit smaller, same boot error

I think you really hit the RAM boundary. Then the only option is to move functions from RAM to flash.

I added ICACHE_FLASH_ATTR to all of my functions. However, this does not have any impact as ICACHE_FLASH_ATTR seems to be the default within the Sming build system anyway. So perhaps the RAM is be used up by the SDK already :-(

[hreintke]

@tius2000 :
Yes, the default in Sming is ICACHE_FLASH_ATTR

In the generated "out\firmware\firmware.map" file is the detailed information on functions and rom/ram locations. Do not have yet the complete knowledge on identifying "unnecessary ram located" functions.
If you can help with that we might improve this.

[tius2000]

Thank you very much @hreintke! I will have a look at this and will report any success :-)