Why does noinit section get initialized after a reset of LPC54S018M?

[rex_lam]

I have an LPCXpresso54S018M (LPC54S018M-EVK) board. I am trying to set up a noinit section in SRAM0:

    /* MAIN DATA SECTION */

    /* DEFAULT NOINIT SECTION */
    /* This must be the first section in SRAM_0_1_2_3 */
    .noinit (NOLOAD): ALIGN(4)
    {
        _noinit = .;
        *(.noinit*)
         . = ALIGN(4) ;
        _end_noinit = .;
    } > SRAM_0_1_2_3

In my code in both images, I allocated the following variable in the noinit section:

__NOINIT_DEF MyFlags my_flags;

Every time the MCU resets (without losing power), the value 0xBF30B671 is written to every word in SRAM_0_1_2_3. This defeats the purpose of the noinit section. I have tried with images from both MCUXpresso and Keil, and both produce the same result. It seems to be a property of the MCU, and not the compiler.

Could someone tell me how to successfully add a noinit section to SRAM0 on the LPC54S018M please?

[yuanwei_wu]

From design team, the description about SRAM initialization is as below:

Rom fills the SRAM with 0xbf30b671 Value. This value corresponds to opcode for setting the CPU to locked state. So if CPU is made to jump to un-initialized SRAM then it will immediately lock the part instead of executing unknow code.  This was done to avoid attacks on the device by loading virus code in to SRAM and making CPU jump to it through glitch attacks.

Only last 1KB of SRAM is left untouched by ROM. This depends on the phantom part customer is using. For example, if the part has all possible SRAMs enabled then untouched memory will be 0x20027FC00 - 0x20027FFFF. IF only SRAM0, SRAM1 and SRAM2 are enabled then the untouched area will be 0x2001FC00 - 0x2001FFFF

[rex_lam]

I found out the fixed value written to the entire SRAM after a reset is intentional, for security reasons. I will have to find another way to do what I need. I thought I should update this post in case anyone else encounters the same issue. Thank you to all who have responded to the question.

[belmontbob59]

Up. Could we get an answer from NXP on this matter?

Is it expected behavior that the BOOT ROM purposely fills up SRAM with pattern 0xbf30b671  upon MCU reset ? This seems like a departure from "regular" behavior from other LPC families (17xx, 18xx...).

546xx's BOOT ROM (54xxx family) DOES NOT fill up SRAM with 0xbf30b671. SRAM remains untouched by BOOT ROM across reset.

This behavior seems oddly specific to 54S018M... Does LPC54S018M have a bug and if so will errata reflect that?

[converse]

What are you expecting noinit to do? It tells the compiler not to touch whatever values are in that region of memory.

[rex_lam]

I expect the noinit memory to contain what I write to it, even after an MCU reset. The issue isn't with what's there after power up. The issue is with what is not there after a software reset. If the MCU always writes to RAM during a reset, then I cannot put data in RAM before a reset to direct behavior after a reset.

[BlackNight]

The linker by default creates data which is used by the startup code to initialize variables (with values like 'int i = 3' or'zero-out' for not initialized variables. With NOLOAD you mark a section that the linker shall not prepare 'loading' information, exactly what you need in your use case, which is similar to the battery backup RAM descirbed in GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse 

I hope this helps,

Erich

[rex_lam]

Erich,

Thank you for confirming that I am using NOLOAD correctly. Your link is very informative and helpful in troubleshooting this issue. Unfortunately, something is writing 0xbf30b671 to every word in SRAM during a reset of LPC54S018M before ANSI startup code runs. As a result, my noinit section does not retain the values that had been written prior to the reset.

Is this expected behavior in LPC54S018M? Is there any way to disable the writing of 0xbf30b671 to SRAM during a reset?

Rex

[belmontbob59]

"something is writing 0xbf30b671 to every word in SRAM during a reset of LPC54S018M"

The BOOT ROM is writing 0xbf30b671 in all SRAM/SRAMx because if you put a breakpoint in the reset handler (before main() 's ANSI init code had a chance to even run) the entire memory is already filled up with 0xbf30b671.

[converse]

I think you need to move the NOLOAD spec in your script.

See GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse 

[rex_lam]

Thank you for replying. Can you be more specific about where to move the NOLOAD spec? The same script works correctly on LPC54605 so I do not know what is wrong with the placement of NOLOAD. I really need a way to ensure a portion of RAM is not modified after a reset. Any help is greatly appreciated.