AnsweredAssumed Answered

S32K1xx bootloader: separate projects and RAM content during reset

Question asked by Joao Roscoe on Jan 16, 2019
Latest reply on Jan 24, 2019 by Joao Roscoe

I'm in the early stages of a project that uses S32K144 and will require a custom bootloader. My intention is to go the KISS way, so my basic idea is:

* Create separate projects for the bootloader and for the main application, with proper locator scripts, to ensure they won't mess with each other's memory usage

* Create separate interrupt vector tables for the bootloader and for the main application;

* Create a startup flag in RAM, to be used by bootloader to choose what to do: keep running the bootloader or hand over control to main application;

* Handover control to application really early, before unmasking interrupts, to avoid the need of fancy handover code (except for the inevitable VTOR change, and possibly some stack tweaking);

* Switch from main application to bootloader only via reset (after writing to RAM the proper statup flag);

 

My questions:

1. Can I rely on the (previously written) content of a RAM location, right after a CPU reset ?

2. What would be the best way to perform a software reset ?

3. Is it possible, with S32DS for ARM / openSDA / S32K144EVB, to flash two separate firmwares to work together? According to the tests I did, so far, just running the two builds in Debug mode, sequentially, won't do, it seems that the second flashing compromises the first one;

4. Is it possible, with S32DS for ARM /openSDA / S32K144EVB, to load the symbols of two different, separate, builds, to debug the handover process?

 

Thank you in advance for your time,

Joao

Outcomes