question about Memory segment in bootloader and relative user application

[vegetarian1]

Hello,

I fill the MEMORY segment of linker file for bootloader according to chip memory map, And it should be filled for user application too follow some documents. I want to know if the location in MEMORY segment are important for user application except the location of code storage. Because only the code in user application would be burned to flash by bootloader, I guess the location would not be used except code storage for user application if it is burned by bootloader. The whole MEMORY segment for user application would be used only when running without bootloader. Am I right?

Thanks for your attention!

[vegetarian1]

Change to another point of view. Both bootloader and user application have IntcIsrVectorTable, but reside in different addresss (in flash). The bootloader downloads user application firmware and involve functions in it. Which IntcIsrVectorTable would be used then? I think the bootloader's. I think The IntcIsrVectorTable used for user application would be used only when no bootloader exists and running user application directly. e.g. download user application firmware by s32ds. Right?

Thanks for your attention!

[ErichStyger]

Hi @vegetarian1 ,

see for example https://mcuoneclipse.com/2013/04/28/serial-bootloader-for-the-freedom-board-with-processor-expert/co... if you are new to bootloaders.

Yes, there are two vector tables: one for the bootloader and one for the application. The bootloader switches the VTOR (Vector Table Origin) to the application vector table in the process jumping to the application. So both vector tables exist, but only one is used at a time.

I hope this helps,

Erich

[vegetarian1]

Hi, @ErichStyger 

Thank you very much!

Is it necessary to allocate different running space(RAM) for bootloader and user application separately?

Thanks for your attention! 

[ErichStyger]

That again depends on your application:

if you have the the usual scenario that after reset the bootloader runs and then the application, you don't need to separate the memory.

But if you have the use case that the application can call the bootloader and expects to return to the previous application state, you would have to make sure that the memory is not used twice. Such a scenario usually exists for ROM bootloaders where you are using functions of it, and the ROM bootloader requires extra memory (e.g. for programming).

I hope this helps,

Erich

[vegetarian1]

This topic is interesting!

The bootloader and user application use the same memory in the usual scenario. The application run after bootloader, and then the memory used by bootloader is covered during initialization of application(I guess), so all running infomation used by bootloader gets lost, and can not return to bootloader function. Right?

Thanks for your attention!

[ErichStyger]

Hi @vegetarian1 ,

it is all up to you how you want it. I mean you control your application startup code, and it is you who can decide what gets re-used and what not.

See GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse for the concept.

Erich

[ErichStyger]

Hi @vegetarian1 ,

Using FILL is a good thing to make sure everything is erased. But it is only really necessary if you are using a CRC, because if the binary has some gaps in the memory map every flash cell needs to have defined value (see Tutorial: CRC32 Checksum with the KBOOT Bootloader | MCU on Eclipse).

I hope this helps,

Erich

PS: it is not only code which ends up in FLASH, but as well all constant data.