• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 479 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: Change in abort-handling in SDK 08.06

Felix Heil
Expert 1185 points
Part Number: MCU-PLUS-SDK-AM243X

Hello,

currently we are still updating to SDK 08.06 and I noticed that there was a rename in the abort-handlers from HwiP_data_abort_handler to HwiP_data_abort_handler_c.

I also saw the reason for this but did not quite completely understand. The abort_handlers asm-file now has a assembly-routine before and after calling HwiP_data_abort_handler_c. If I understood that right, this routine makes sure the -8 or -6 (thumb) is applied on the LR-register, like it is written in the arm-documentation.

We previously used our own abort-handlers in simply overwriting the ones in the SDK. Since this change was included I would say I just rename our abort-function to "HwiP_data_abort_handler_c" also and make sure it is linked.

Inside the abort-handlers I copied out LR and SP and stored them inside a NOINIT RAM-section to get the values after a warm reset. Do I need to care about something new now? As I understood the assembly is in thumb mode (at least according to the makefile compile-flags), that's why a -6 is applied to the LR I guess. Our abort-handler itself is not compiled in thumb. Could this bear some problems?

Best regards

Felix

  • 0
    TI__Prodigy 580 points
    Hi Felix,

    We have renamed our old data abort handler to

    void __attribute__((interrupt("ABORT"), section(".text.hwi"),weak)) HwiP_data_abort_handler_c(void)

    We have defined HwiP_data_abort_handler_c as a weak function so that user can define callback function with the same name in their application.

    Data Abort handler starts execution in HwiP_data_abort_handler, defined in HwiP_armv7r_handlers_nortos_asm. S, After some initial assembly logic it then branches to HwiP_data_abort_handler_c defined in HwiP_armv7r_handlers_nortos.c

    after exiting from this HwiP_data_abort_handler_c(void) it does some more assembly to return to the next instruction.  We are subtracting LR-6 in thumb or LR-4 to get the correct return address by checking the SPSR register. 

    I think you are intrested in saving the instruction that rasied that abort, for that you need to add your code in the HwiP_data_abort_handler as inside the HwiP_data_abort_handler_c  LR and Sp will differ.

     >> Our abort-handler itself is not compiled in thumb. Could this bear some problems?

    Handlers will operate on arm mode by default irrespective of on which mode you have compiled.

    Let me know if you have any questions on this.
  • 0 in reply to Abishek S S
    Expert 1185 points

    hey Abishek,

    thanks for the explanation! We did this in the past by just commenting the handlers inside the sdk and defining our own handlers.
    But what I noticed is, that now in the "HwiP_data_abort_handler_c" LR and SP are not the correct values, but those of the abort-handler-call it self. I noticed LR and SP of the abort-producing instruction are pushed onto the abort-handler-stack.

    How can I retrieve them safely? Is it ok to just take the SP of the abort-handler and subtract to reach LR and SP or are there better possibilities?

    Best regards

    Felix

  • +1 in reply to Felix Heil
    TI__Prodigy 580 points

    >> Is it ok to just take the SP of the abort-handler and subtract to reach LR and SP or are there better possibilities?

    Yes, you can do that ..

    /* Restore used registers, LR and SPSR before returning. */
    POP {LR}
    MSR SPSR_cxsf, LR
    POP {LR}
    POP {r0-r4, r12}

    After this instruction the LR and SP will same as the aborted state value. You can add your logic after this code.

    Also, could you explain a bit more what are you doing inside the data abort handler?

  • 0 in reply to Abishek S S
    Expert 1185 points

    Ah great!

    This is mainly for our releases. We have a defined place inside the RAM which is NOLOAD like this:

    .errorTable (NOLOAD): {} palign(ERROR_TABLE_SIZE) > MCU1_0_ERROR_TABLE

    If the abort-handler is called in a release-fw the device should not hang up but automatically restart. To identify the reason for that abort we will save the LR and SP, and if set, read them out and make them available via a log after the restart. The plan is that in such cases the service or customer can just send us this error-log with the version he uses and so on. than we can use the created map-file of this version and at least get some idea where the abort comes from.

    It's only a small but sometimes helpful feature.