This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48x context save/restore for STC

Other Parts Discussed in Thread: HALCOGEN

As the STC will generate a reset upon completion of the self tests, our application might need to perform a context save prior the STC self test as well as a context restore after reset generated by STC. Chapter 8.2.2 (Context Saving) of the Reference manual states that "Following are some of the registers that are required to be backed up before and restored after self-test."

To be honest, I don't think it is helpful to mention only some of the registers that require to be saved/restored. Developers need information about all of the registers that need to be saved. Is there a complete list of registers that need to be context saved/restored?

Furthermore, even knowing the complete registers required to save I suspect it might not be a trivial task to implement complete context save/restore functionality from scratch. Assuming that the requirement for context saving/restoring is rather common among RM48x safety applications: Is there any sample code for complete context save/restore on RX48x based microcontrollers?

Kind regards,

Erik von Hesse

  • Erik,

    I've asked our expert to have a look to your question.
    In the mean time, I've found this thread. It may help you.

  • Jean-Marc,

    did your experts come up with some suggestions?

    Have any of you guys ever heard that someone implemented such a complete reset context saving/restoring successfully? I still have my doubts about the feasibility.

    In the forum I only find partial solutions. What I would like to have at least would be a complete list of registers that need to be context saved to recover from reset. A complete coding sample would be greatly appreciated.

  • The reality is, many (not to say all) customers are performing the CPU Self test on power on only.
    From a safety standpoint this is enough. Doing this selftest by interval at run time is really time consuming because of the context save/restore.

    This context switch to be optimum is application dependent. Mainly, all CPU, Coprocessor (CP15) and VFP registers that are used in the application have to be saved. Used means, that the application code is changing (writing) their default reset value.
    Based on this statement, all CPU registers R0 to R12 including all banked registers, CPSRx and SPSRx, SPx, LRx have to be saved. Same for all VFP registers (if the VFP is used in the application)
    The CP15 registers have also to be saved. Depending on the initialization code used in your application, this list may differ. Halcogen startup code is configuring some of them depending if ECC is used or not, to overcome some ARM errata, and other performance tuning.

    These are the reason, to test on power on reset is the preferred solution. The boot code will check if the reset condition is a power on reset (in this case the CPU self test will be executed) or, if it is a warm reset, the test can be skipped.

    Can you tell me in which kind of application the part will be used?

  • I don't think a context switch would consume a lot of processing time, I just think it consumes a lot of development time. I think you forgot to mention the MPU registers that also need to be context saved.

    Our project is to implement a safety library for a customer. The customer had the execution of STC in regular intervals at runtime as a requirement. Thus we cannot assume anything about the application. We have discussed the situation regarding context save/restore with our customer and he fortunately agreed that this solution is not feasible without further secure information or secure sample code from TI, so we will fall back to executing the STC at startup only.

    Thanks for your assistance anyway, Jean-Marc.

  • I just see that the MPU is part of the Coprocessor Register, so you didn't forget to mention it. Sorry for that.