RAM usage of LPC804 boot ROM

[jforslof]

Our application needs to preserve a block of RAM memory across software reset. This requires selecting an area which the boot ROM will not overwrite during the reset.

Which areas of RAM are guaranteed to not to be overwritten by any previous of future versions of the LPC804 boot ROM? I am only interested in normal reset and IAP programming, ISP mode is not required.

The user manual defines the memory usage of the bootloader in the sections quoted below and I had interpreted the text as the boot ROM using 0x1000 0128 - 0x1000 03A7 and 0x1000 0FE0 - 0x1000 0FFF only.

We have recently encountered a problem with memory outside of these ranges being overwritten on reset. Debugging shows that version 13.1 of the boot ROM places its initial stack at the end of RAM and adopting a lower stack only on entering ISP mode. This ends up overwriting the top 44 bytes (0x1000 0FD4 - 0x1000 0FFB) during a normal startup.

Our earlier testing may have used a different ROM version using less stack space. I am have not been able to confirm this, however it leaves me reluctant to relocate the memory usage of our application without a well-defined memory usage specification.

Thank you in advance for your support.

Regards,
Johan 

---

Excerpt from UM11065 rev 1.3 (pages 15, 21 and 34):

3.5.1 Memory map after any reset
The boot ROM block is 8 KB in size. The boot block is located in the memory region starting from address 0x0F00 0000. The bootloader is designed to run from this memory area, but both the ISP and IAP software use parts of the on-chip RAM. The RAM usage is described in Section 4.3.7 “ISP interrupt and SRAM use”. The interrupt vectors residing in the boot block of the on-chip flash memory also become active after reset, that is, the bottom 512 bytes of the boot block are also visible in the memory region starting from the address 0x0000 0000.

...

4.3.7 ISP interrupt and SRAM use

...

4.3.7.2 RAM used by ISP command handlers
The stack of UART ISP commands is located at address 0x1000 03A8. The maximum
stack usage is 640 bytes (0x280) and grows downwards.
The ISP flash programming commands use the top 4 bytes of on-chip RAM.

4.3.7.3 RAM used by IAP command handlers
The IAP flash programming commands use the top 4 bytes of on-chip RAM.

...

4.6 IAP commands

The flash memory is not accessible during a write or erase operation. IAP commands,
which results in a flash write/erase operation, use 32 bytes of space in the top portion of
the on-chip RAM for execution. The user program should not be use this space if IAP flash
programming is permitted in the application.

[jforslof]

For what it is worth I notice that the AN12378 SPI bootloader stores reset persistent state in RAM (see SL_ADDRESS_x in si_protocol.h of https://www.nxp.com/docs/en/application-note-software/AN12378SW.zip), implying that at least 0x1000 0000 - 0x1000 0007 are untouched by the boot ROM on reset.

Unfortunately this specific memory block is unsuitable for our application which needs 256 bytes located higher up in RAM since our stack is located at the bottom to ensure hardware protection for stack overflow. Ideally as high as possible to since our linker requires manual handholding to exploit a fragmented RAM area.

Regards,

Johan

[diego_charles]

Hi @jforslof 

I hope you are doing well!

Thank you for the additional information! I currently discussing the topic with a colleague. Please provide me additional time to deliver feedback.

Just to confirm, your application requires to maintain un-altered 256 bytes ( at the highest location as possible ) in SRAM  after the assertion of the external RESET pin, and the execution of any other process like IAP and ROM  bootloader?

All the best,

Diego

[jforslof]

Thank you for your swift response Diego!

That is correct but to clarify we do not use or care about the actual ROM bootloader (ISP mode) but only about the memory usage of the ROM startup code up to entering the application in FLASH.

The application also invokes IAP and set_fro_frequency functions in ROM and needs to know their memory usage so that it does not overwrite this 256-byte buffer or any other application state.

(On a related note I would urge that the maximum stack usage of the IAP and other ROM functions be documented to allow application authors to select suitable margins.) 

Regards,
Johan

[diego_charles]

Hi @jforslof 

Thank you for the additonal information! 

Today I tryed to replicate  the behaviour that you mention, could you help me to take a look ?

I wrote in the  32 bytes at the top of the SRAM with a pattern of  letters, then I wrote on the following 256 bytes a sequence of numbers. Then , using the debugger session on MCUxpresso I just hit reset, and see that the 32 bits at the top of the SRAM have been changed, and the following 12 bytes of the SRAM changed. Meaning that 44 bytes changed after executing the reset handler and reaching the first instrucction on main.

All the best,

Diego.

[jforslof]

Hello Diego!

Yes, your results are entirely consistent with by findings for boot ROM version 13.1. The topmost 44 between get overwritten during a normal device reset.

Taking a look at the code I see that the cookie word at the end of RAM is written along with 10 words of stack space for caller-saved registers for all paths unless ISP mode is entered.

As a place-holder workaround I have moved our buffer to reserve 64 bytes for the boot ROM startup code. Of course our concern is that without a clear API contract on who owns what memory this may get us into trouble in the future.

Regards,
Johan

[diego_charles]

Hi @jforslof 

Thank you for your reply and extra details.

Please,  provide me additional detail to give you  feedback. I am currently checking with my colleagues.

All the best

Diego.

[jforslof]

Hello @diego_charles!

Can you elaborate a little bit on what additional feedback you require?

As per the analysis below the startup memory usage of boot ROM version 13.1 is consistent with measurements and so I am satisfied that it is predictable. My concern is that a future device revision may introduce an updated firmware using additional memory, breaking our device.

For the moment we have proceeded by reserving 64-bytes at the top of RAM from 0x10000FFC0 to 0x10000FFFF for use by the startup code. That is 20 bytes of margin as compared to current actual usage.

Regards,
Johan

[diego_charles]

Hi @jforslof 

My apologies for not getting back to you in the meantime!

I have been performing tests by my side and talking with applications engineer regarding this during this time. 

The LPC804 only have 2 chip revisions: 1A and 1B, both use Boot ROM version 13.1, so all LPC804 chips have same SRAM usage. Since the usage it is  replicable you can place the buffer below the 44 bytes. it should preserve its data after reset. 

That 64  bytes margin sounds reasonable. I am inquiring to know if there will be any Boot ROM  update near in the future. 

My apologies for any inconvenience. 

Diego.

[diego_charles]

Hi @jforslof 

Thank you for your patience.

I confirmed that there are no Boot ROM updates scheduled for now. Unfortunately, I am not able to tell what will be the SRAM usage for an upcoming Boot ROM version.

My apologies for this typo in this phrase: "Please provide me additional details to give you feedback", I meant additional time instead of details. I missed that.

If I can help you further, please let me know.
Diego.

[jforslof]

Hello Diego!

Thank you for your interest. Can you elaborate a little one what particular additional details you require?

To clarify my basic concern is that the memory usage of the boot ROM on reset appears not to be documented. This makes it difficult to know where application RAM buffers required to survive a reset should be placed.

The observed behavior is that boot ROM version 13.1 code places its stack at 0x10000FFFC (technically 0x10000FFFF but the M0+ appears to silently ignore the stack misalignment). The initialization code prior to application entry then use a maximum total depth of 10 words of stack frame space unless ISP mode is invoked, in which case 14 words are used and a new stack in low memory is selected. A cookie word at 0x10000FFFC is also reset.

The pseudocode below shows the sequence of nested function calls with the +X annotation before a call indicating the stack frame size in 32-bit words and the @ suffix the location of the function in ROM.

ResetThunk @ 0x0F0000A4() {
 Init() @ 0x0F0000AC {
  crp_unlock;
  SP = (void *) 0x10000FFFF;
  +4: Startup @ 0x0F000420() {
    hardware_init;
    +2: NvmInit @ 0x0F001420() { ... }
    *(uint32_t *) 0x10000FFFC = -1;
    +0: Unlock() @ 0x0F001D18() { ... }
      if(!wdog_reset && !PIO0_12 && CRP == ISP_ALLOWED)
        +4: ISP @ 0x0F00035A();
        +2: StartApp1 @ 0x0F00040E() {
          +4: StartApp2 @ 0x0F0003D2() {
            if(app_vector_checksum == OK) {
              +0: InvokeVector @ 0x0F0000E4() {
                call_application_reset..;
            }
          }
        }
        +4 ISP @ 0x0F00035A();
      }
    }
  }
}

 Regards,
Johan