Discuss here different C compiler set ups, and compiling executables for the ESP8266

User avatar
By projectgus
#18687
jcmvbkbc wrote:Actually there's 64KB, at least OTA boot code uses memory in the upper 32KB, I guess we can use full 64KB if OTA functionality isn't needed.


That's very interesting, thanks.

I just tried writing to the upper 32KB of IRAM via openocd, while running the RTOS SDK. The region reads back as all zeroes. Writing to the lower 32KB works as expected.

I wonder if this relates to the flash caching behaviour somehow? You can either have that region mapped to address space, or used as cache?

Just unmapping the flash (clearing bit 17 of 0x60000208) wasn't enough to change anything.
User avatar
By jcmvbkbc
#18689
projectgus wrote:
jcmvbkbc wrote:Actually there's 64KB, at least OTA boot code uses memory in the upper 32KB, I guess we can use full 64KB if OTA functionality isn't needed.


That's very interesting, thanks.

I just tried writing to the upper 32KB of IRAM via openocd, while running the RTOS SDK. The region reads back as all zeroes. Writing to the lower 32KB works as expected.

Interestingly, I write it through openocd from gdb console and data is read back as expected, even if I quit both gdb and openocd and reconnect. The core is running in ROM at that time. But if I do it from the firmware I also only see zeros.
User avatar
By jcmvbkbc
#18698
projectgus wrote:I wonder if this relates to the flash caching behaviour somehow? You can either have that region mapped to address space, or used as cache?

Just unmapping the flash (clearing bit 17 of 0x60000208) wasn't enough to change anything.

The following thing disables high 32KB of IRAM (ROM code in the range 4000476b...4000477a):
*(uint32_t*)0x3ff00024 |= 0x18;

To be more precise it's the bit 0x10.
This is done as one of the last steps in the Cache_Read_Enable.
Clearing that bit enables high 32KB of IRAM.

I'm suspecting that these 32KB are used as the FLASH cache, which apparently is 32KB too.