noinit RAM section in LPC55S16

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

noinit RAM section in LPC55S16

2,328 Views
janpieterderuit
Contributor IV

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-re...

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

Labels (1)
0 Kudos
12 Replies

2,197 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello janpieterderuit,

About reserved range , please refer to the result below:

Alice_Yang_0-1640240201338.png

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.

 

BR

Alice

0 Kudos

2,293 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello janpieterderuit,

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

 

BR

Alice

0 Kudos

2,284 Views
janpieterderuit
Contributor IV

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:

janpieterderuit_0-1639517972228.png

  • 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

0 Kudos

2,263 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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.

 

BR

Alice

 

 

0 Kudos

2,257 Views
janpieterderuit
Contributor IV

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

0 Kudos

2,243 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello 

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

Alice_Yang_0-1639992747971.png

 

BR

Alice

 

 

0 Kudos

2,239 Views
janpieterderuit
Contributor IV

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-bootload...

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))

0 Kudos

2,236 Views
janpieterderuit
Contributor IV

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

0 Kudos

2,207 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello janpieterderuit,

Does your chip enter ISP mode?

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

 

BR

Alice

0 Kudos

2,202 Views
janpieterderuit
Contributor IV

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)...

0 Kudos

2,280 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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.

 

BR

Alice

0 Kudos

2,314 Views
janpieterderuit
Contributor IV

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

0 Kudos