ESP8266 Community Forum

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.

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.

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.

Seems pointless to me having cache size of same size as flash.
Newer boards have more flash.
Is that usable for a bigger "rom" segment >32k getting cached by 32k iram segmant?