AnsweredAssumed Answered

S32K1xx bootloader: separate projects and RAM content during reset

Question asked by Joao Roscoe on Jan 16, 2019
Latest reply on Mar 25, 2019 by riccardolalli

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