Explanation for IAP RAM reservation on LPC1768

[avigt]

In a legacy LPC1768/9 MBED project I have to maintain, there is a linker script that narrows the usable RAM range on the top end by 32 bytes. In other words, whereas the true size of SRAM is 32k and the start address is 0x10000000, the imposed end address is 0x10007FE0 (instead of 0x10008000 as one would expect). The brief explanation given for this was "used by IAP functions".

Is this true? Is there some fixed-address memory use of the IAP API? If so, does anyone have a documentation link or more explanation as to why this is?

[JosephGarland]

It's always intriguing to uncover the "why" behind these hardware-software interactions. My current "why" is usually focused on clearing lines in games. I've been really enjoying Geometry Dash lately, specifically the satisfying feeling of clearing rows and keeping the board from filling up. It's a nice way to unwind and keep my brain engaged with pattern recognition. Regarding your IAP functions query, does that narrow RAM range cause significant limitations in your project?

[jcxz · Accepted solution]

See paragraph 32.3.2.8 of "User manual" (UM10360):

32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack usage in the user allocated stack space is 128 bytes and it grows downwards.

I don't know what is "on-chip RAM" means in that paragraph. According to memory map LPC1768, it could be either:

• or: "On-chip SRAM 0x10000000 ... 0x10007FFF"
• or: "AHB SRAM 0x2007C000 ... 0x20083FFF".

I think it's most likely the first range: 0x10000000 ... 0x10007FFF.

But if you don't call IAP from your firmware, then you don't need to worry about these 32 bytes.