LPC546xx: .noinit doesn't work as expected

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC546xx: .noinit doesn't work as expected

219 Views
giusloq
Contributor III

I'm writing a second bootloader and I'd like to use a magic number to decide if staying in bootloader or running application. Something similar to this:

 

#include <cr_section_macros.h>
#define START_APPLICATION_MAGIC			0x4C514400
static __NOINIT_DEF uint32_t start_application;

if (start_application == START_APPLICATION_MAGIG) {
  run_application();
} else {
  /* Stay in the bootloader and waits for new application image
   * to write in the Flash. After... */
  start_application = START_APPLICATION_MAGIC;
  NVIC_SystemReset();
}

 

Of course, start_application variable shouldn't be zeroed at reset and during startup code. I already used this tecnique in other applications.

Now, the linker puts start_application at address 0x2000149C and it is marked as .noinit in the map file. However it doesn't work.

If I put a break point on NVIC_SystemReset() instruction, I can see the magic number in start_application variable. When I proceed I stop the execution with another breakpoint in ResetISR(), before initializing bss and data sections. Now I see 0 at address 0x2000149C.

I tried to investigate deeper and I noticed all the address starting from 0x20001000 are zero at startup, while previous addresses (4kB) maintain values before reset.

Why this behaviour? I can't understand. The only reason for this could reside in the bootloader in ROM that should always start. However I don't know how much SRAM it uses and where.

0 Kudos
6 Replies

189 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello giusloq,

Check your startup file, maybe fill zero with uninitalized data, for example MCXUpresso IDE:

Alice_Yang_0-1649313198919.png

 

BR

Alice

 

0 Kudos

187 Views
giusloq
Contributor III

Check your startup file, maybe fill zero with uninitalized data

I  put a breakpoint at the beginning of ResetISR(), before initializing bss and data sections.

Even at this point, the variable that was initialized with a magic number before the reset appears again to zero.

I suspect it's a behaviour of ROM bootloader. Do you know if the ROM bootloader uses SRAM? If yes, which part of SRAM are touched by bootloader?

0 Kudos

164 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

 

Hello giusloq,

Enter ISP mode, then use blhsot command "get-property 12":

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

Below picture is or lpc55xx:

Alice_Yang_0-1649409632104.png

 

BR

Alice

 

0 Kudos

213 Views
carstengroen
Senior Contributor II

Not that it in any way is an answer to your problem...

On the LPC54x I use the RTCC RET RTC->GPREG registers for stuff like that (also when activating bootloader etc)

RTCC->RET[31].REG != 0xDEADBEEF 

Correction, its RTC->GPREG[]

You just need to initialize the RTC before accessing the registers.

As I said, not a solution for your problem, just another way of solving the job

0 Kudos

206 Views
giusloq
Contributor III

On the LPC54x I use the RTCC RET registers for stuff like that (also when activating bootloader etc)

Do you mean GPREGx, general purpose register, don't you? Because I can't see RET registers.

Is LPC54x a different MCU than LPC546xx?

0 Kudos

201 Views
carstengroen
Senior Contributor II

Sorry, yes, too many different targets here

I meant:

RTC->GPREG[7] != 0xDEADBEEF 

0 Kudos