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
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.
BR
Alice
Hello janpieterderuit,
Could you please share a simple project that can reproduce the issue, I will help to confirm.
BR
Alice
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:
/* 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
__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;
CLOCK_EnableUsbfs0DeviceClock(kCLOCK_UsbfsSrcFro, CLOCK_GetFroHfFreq());
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);
noinit_var_DEFAULT++;
noinit_var_USB_RAM++;
noinit_var_NOINIT++;
My expected results are:
But this is the result:
I attached my example project.
Thanks in advance for your help!
BR, Jan Pieter de Ruiter
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
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
Hello
The ROM reserved regions can be obtained from the blhost command "get-property 12".
BR
Alice
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))
Note: I use the LINK2 USB connection on my dev board, which shows up as COM10.
Hello janpieterderuit,
Does your chip enter ISP mode?
If no, please check UM to enter ISP mode, then can use blhost.
BR
Alice
Yes, it does enter ISP mode:
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)...
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
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