Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MCU reset and internal SRAM starting values

18 views
Skip to first unread message

pozz

unread,
Apr 6, 2022, 7:37:56 AM4/6/22
to
I often use with success a simple way to implement a bootloader:


#define START_MAGIC 0xAA55AA55
uint32_t start_application __attribute__((section=".noinit"));

void main(void) {
...
if (start_application == START_MAGIC) {
start_application = ~START_MAGIC;
launch_application();
}
/* Stay in bootloader and wait for new application from
* USART, SPI, USB, whatever. */
...
start_application = START_MAGIC;
ResetMCU(); /* It's NVIC_SystemReset() */
}


I don't use launch_application() after download, because I think it
isn't good to start the application with some already configured
peripherals (USART, SPI, USB). I know I can deinitialize peripherals and
clocks before launch_application(), but the technique above it's much
more simple.
Of course, start_application variable shouldn't be touched after a
reset, so I put it in noinit section.

Recently I tried to implement a bootloader on a LPC546XX from NXP and I
noticed it didn't work. After some investigation I found that
start_application variable is reset to zero immediately after ResetMCU().
After other investigation I noticed that the first 4kB space of SRAM
doesn't change after a reset, while the next 4kB space is really put to
zero.
I changed the location of start_application variable to the first 4kB
space and the bootloader started working perfectly.

This is the first time I see this behaviour, so my question.

When can you trust that internal SRAM content isn't changed when the MCU
core is reset?

Stef

unread,
Apr 6, 2022, 8:07:16 AM4/6/22
to
The LPC546XX seems to have a quite complicated boot process that
validates boot images. It may use (and afterwards clear?) some ram for
that?

--
Stef

Happiness isn't having what you want, it's wanting what you have.

pozz

unread,
Apr 6, 2022, 9:45:24 AM4/6/22
to
Il 06/04/2022 14:07, Stef ha scritto:
> On 2022-04-06 pozz wrote in comp.arch.embedded:
[...]
>> When can you trust that internal SRAM content isn't changed when the MCU
>> core is reset?
>
> The LPC546XX seems to have a quite complicated boot process that
> validates boot images. It may use (and afterwards clear?) some ram for
> that?

Good point, LPC546XX has a ROM bootloader that always starts at the
beginning (and I think even after a software reset like NVIC_SystemReset).

However I couldn't find any info about the SRAM it uses, but this could
explain the behaviour I observed.


0 new messages