topic Re: noinit RAM section in LPC55S16 in LPC Microcontrollers

noinit RAM section in LPC55S16

janpieterderuit — Thu, 09 Dec 2021 03:49:00 GMT

Hi,

we are trying to create a noinit (NOLOAD) section in RAM of the LPC55S16, so we can have variables in RAM which will survive a SW reset.

But when we are trying to read those variables, data seems to have been overwritten, it does not contain data we would expect.

So I did some searching, and found a related post:
https://community.nxp.com/t5/LPC-Microcontrollers/Why-does-noinit-section-get-initialized-after-a-reset-of/m-p/935806#M37298

In short: in this LPC (LPC540xx), RAM s overwritten for security reasons.
Only a small portion atthe last bit of RAM area is left untouched.

Could it be that the LPC55S16 has the same 'feature'?
I couldn't find any info about it in the documentation.
If so, can you tell me if and which part of RAM is untouched at reset?

BR,
Jan Pieter de Ruiter
Airios

Re: noinit RAM section in LPC55S16

janpieterderuit — Wed, 08 Dec 2021 21:39:28 GMT

I did some testing myself, and it seems that at least the last 256 bytes (the size we need) of RAM (RAM2) is not overwritten on reset.

But I would like to have a confirmation that this is correct

Re: noinit RAM section in LPC55S16

Alice_Yang — Mon, 13 Dec 2021 03:55:45 GMT

Hello janpieterderuit,

Could you please share a simple project that can reproduce the issue, I will help to confirm.

Alice

Re: noinit RAM section in LPC55S16

janpieterderuit — Tue, 14 Dec 2021 21:50:48 GMT

Hi Alice,

Yes, I created a small example project to show what is working and what is nt working as expected.

this is what I did:

I took the hello world example as basis
I splitted the RAM (SRAM) memory, to have a very small section for my noinit at the very end:
- RAM (SRAM): address: 0x20000000, size: 0xFFF8
- RAM4 (SRAM_NOINIT): address: 0x2000FFF8, size: 0x8
I created a noinit section in this new memory area in the loader file:

/* NOINIT section for SRAM_NOINIT */ .noinit_RAM4 (NOLOAD) : ALIGN(4) { PROVIDE(__start_noinit_RAM4 = .) ; PROVIDE(__start_noinit_SRAM_NOINIT = .) ; *(.noinit.$RAM4) *(.noinit.$SRAM_NOINIT) *(.noinit.$RAM4.*) *(.noinit.$SRAM_NOINIT.*) . = ALIGN(4) ; PROVIDE(__end_noinit_RAM4 = .) ; PROVIDE(__end_noinit_SRAM_NOINIT = .) ; } > SRAM_NOINIT AT> SRAM_NOINIT

I created 3 noinit variables, using macro's from cr_section_macros.h:
1. This is the preferred variable, added at the very beginning of the normal SRAM memory

__NOINIT_DEF uint32_t noinit_var_DEFAULT

2. This variable is placed in the USB_RAM memory.
Because we want to use USB in our application, this is not a workable solution for us.

__NOINIT(USB_RAM) uint32_t noinit_var_USB_RAM;

3. This one will end up in the new memory area, at very end of the normal SRAM

__NOINIT(SRAM_NOINIT) uint32_t noinit_var_NOINIT;

I enabled the USB FS0 Device clock (needed for USB RAM) in clock_config:

CLOCK_EnableUsbfs0DeviceClock(kCLOCK_UsbfsSrcFro, CLOCK_GetFroHfFreq());

After the hello world message over UART I show the value of the 3 noinit variables:

PRINTF("noinit_var_DEFAULT: 0x%08x\r\n", noinit_var_DEFAULT); PRINTF("noinit_var_USB_RAM: 0x%08x\r\n", noinit_var_USB_RAM); PRINTF("noinit_var_NOINIT: 0x%08x\r\n", noinit_var_NOINIT);

And then I increase each variable by 1:

noinit_var_DEFAULT++; noinit_var_USB_RAM++; noinit_var_NOINIT++;

My expected results are:

At powerup each variable will have 'random' values
After a software reset (without a power cycle), each variable will be increased by one

But this is the result:

The variables in USB_RAM and my new SRAM_NOINIT area are increased by 1 on reset: OK
The preferred variable noinit_var_DEFAULT stays the same: NOK
Actually also after a power cycle this variable remains the same

I attached my example project.

Thanks in advance for your help!

BR, Jan Pieter de Ruiter

Re: noinit RAM section in LPC55S16

Alice_Yang — Wed, 15 Dec 2021 09:21:06 GMT

Hello Jan Pieter de Ruiter,

Thanks for your sharing, I have reproduced it, I will confirm and give you feedback once have any information .ASAP.

Alice

Re: noinit RAM section in LPC55S16

Alice_Yang — Fri, 17 Dec 2021 04:28:51 GMT

Hello Jan Pieter de Ruiter,

I have just got reply from SE team as below, share it to you:

Indeed, these modifications to the RAM are caused by the boot ROM initialization. Some regions are just used by it and some others are set to 0xBF30B671. The places used by the boot ROM will depend on the boot process (regular boot or ISP mode).

We don't share the specific regions used by each use case as it could change a little depending on the ROM version, the best approach would be to make sure user defines a region that the ROM won't use. This information can be verified and confirmed after a reset. "

Anyway, we'll double check if we have more information from the ROM team that can help customer define such regions.

I will tell you if have more information.

Alice

Re: noinit RAM section in LPC55S16

janpieterderuit — Fri, 17 Dec 2021 06:43:52 GMT

Hi Alice,

Thanks for the confirmation.

So it seems that using the last part of RAM is the only possibility.

And it would be great to get a confirmation about which region is guaranteed to be not overwritten.

BR, Jan Pieter

Re: noinit RAM section in LPC55S16

Alice_Yang — Mon, 20 Dec 2021 09:32:37 GMT

Hello

The ROM reserved regions can be obtained from the blhost command "get-property 12".

Alice

Re: noinit RAM section in LPC55S16

janpieterderuit — Mon, 20 Dec 2021 10:05:36 GMT

Hi Alice,

thanks for the info.
So I tried the blhost tool.

I first used the version shipped with MCUXpresso (C:\NXP\MCUXpressoIDE_11.4.1_6260\ide\binaries).
I wasn't able to connect at first, but as soon as I did a chip erase, I was able to connect to the LPC55S16 on my dev board.
But I get the following response:

C:\NXP\MCUXpressoIDE_11.4.1_6260\ide\binaries>blhost -p COM10 get-property 12 Ping responded in 1 attempt(s) Inject command 'get-property' Error: read_start_byte() timeout after 5.152 seconds sendCommandGetResponse.writePacket error 5. Response status = 10004 (0x2714) No response packet from target device.

But I noticed the blhost vresion in MCUXpresso is 2.6.5, while you screenshot shows v2.6.7.
So I looked blhost up on the NXP site, and found the latest version here:
https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcu-bootloader-for-nxp-microcontrollers:MCUBOOT

But I get the same response:

C:\NXP\blhost_2.6.7\bin\win>blhost -p COM10 get-property 12 Ping responded in 1 attempt(s) Inject command 'get-property' Error: read_start_byte() timeout after 5.167 seconds sendCommandGetResponse.writePacket error 5. Response status = 10004 (0x2714) No response packet from target device.

I also get the same response with other properties (e.g. 1 (The current version of the MCU bootloader))

Re: noinit RAM section in LPC55S16

janpieterderuit — Mon, 20 Dec 2021 10:10:07 GMT

Note: I use the LINK2 USB connection on my dev board, which shows up as COM10.

Re: noinit RAM section in LPC55S16

Alice_Yang — Wed, 22 Dec 2021 05:57:03 GMT

Hello janpieterderuit,

Does your chip enter ISP mode?

If no, please check UM to enter ISP mode, then can use blhost.

Alice

Re: noinit RAM section in LPC55S16

janpieterderuit — Wed, 22 Dec 2021 20:55:34 GMT

Yes, it does enter ISP mode:

As it's fully erased, it will always go to ISP mode with Auto ISP.
Also when I hold the ISP pin low on power-up, I get the same result
blhost reports "Ping responded in 1 attempt(s)", so I suppose that means that initial UART ISP communication (including baudrate determination) is OK.

By the way:
Chapter 8.3.4.2 from the user manual (UM11295) says the reserved RAM region for the bootloader is only 0x30000000 - 0x30006800 (Fig 18)...

Re: noinit RAM section in LPC55S16

Alice_Yang — Thu, 23 Dec 2021 06:20:15 GMT

Hello janpieterderuit,

About reserved range , please refer to the result below:

About your board connect with blhost, maybe some hardware or other issue, you can try to use Flash Magic to connect,

If still can't work, and you can create a new case about this issue, thanks.

Alice

Re: noinit RAM section in LPC55S16

fsinit — Mon, 24 Mar 2025 16:05:22 GMT

I was also facing the same issue and concluded the same as you. It's unacceptable that nothing has been written about this kind of behaviour.