• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 751 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MCU-PLUS-SDK-AM243X: custom abort-Handler-implementation

Felix Heil
Expert 1265 points

Part Number: MCU-PLUS-SDK-AM243X

Hello,

for our production-release-firmware we would like to implement a behaviour that it stores the abort-producing sp and lr-registers, the type of abort and resets our device in case of an abort.

So far I managed to link against our own HwiP_data_abort_handler and so on. This works, they are called but unfortunately it seems the code does not exectue as wanted. It does just not call the reset-routine and next it lands in an prefetch-abort-handler. probably that's related. is there some cache-mgmt I also need to do?
And how do I access the SP_ABT and LR_ABT-registers? or are those just mirrors of R13 and R14 and can I directly use them?

Best regards

Felix

  • +1
    Expert 1265 points

    ok I think I solved it myself.

    First I had a problem in my own compilation. And it seems lr and sp-abt-registers are just mirrors of R13 and R14. So I can just copy them out with two assembly snipptes.

    but nvtheless maybe I could do some improvements. It works so far, the values get stored, device resets and we can read them from RAM at startup.

    The routine looks now as follows for the data abort but is in fact the same for all the other three (prefetch, undefined, reserved) handlers:

    void __attribute__((interrupt_save_fp("ABORT"), section(".text.hwi"))) HwiP_data_abort_handler(void)
{
     /* data aborts happen in some cases.
     * more reasons: https://developer.arm.com/documentation/ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Exception-descriptions/Data-Abort-exception
     *
     * arm doc: https://developer.arm.com/documentation/dui0471/m/handling-processor-exceptions/data-abort-handler
     * "The instruction that caused the abort is at lr_ABT-8 because
     * lr_ABT points two instructions beyond the instruction that caused the abort."
     */
#ifndef NDEBUG
    /* in debug builds we will loop forever to identify the source of the abort */
    volatile uint32_t loop = 1;
    while(loop)
        ;
#else
    uint32_t programCounter = 0xFFFFFFFF;
    uint32_t stackPointer = 0xFFFFFFFF;
    __asm ("MOV %[res], sp"
      : [res] "=r" (stackPointer)
    );
    __asm ("MOV %[res], lr"
      : [res] "=r" (programCounter)
    );

    __asm ("isb");
    /* call our own abort-handler */
    abortCbC(programCounter, stackPointer);
#endif
}

    Is this a valid way to go or should I do some more adjustments? Should I also call a cache write back Invalidate all?

    Best regards

    Felix