• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 1031 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.

Forcing ARM Exception/Abort Handlers

Mathew Maher49
Expert 2115 points

Hi all,

Just come back from beasting a TMS470 in a radiation chamber. I have to say that the Cortex-M3 does a very good job of identifying errors via it's Hard Fault / Usage Fault / MMU / Bus Fault exception handlers. At the moment my standard response to such events is to reboot the device. However, theres a number of these faults which, if diagnosed correctly, do not require a reboot.

Before I begin to start writing recovery code, the big question is 'how to test'. Short of putting the devices back into a radiation chamber (which is not cheap), does anyone have a method of getting the ARM core to throw valid Aborts, which can be then used to test exception handlers?

Mat

 

 

  • 0
    TI__Guru 59540 points

    Hi Mathew,

    Unfortunately, our TMS470M products do not have the level of capability built in to simulate/force errors of the nature you trying to test. Our TMS570 line of uCs have a far more advanced level of safety diagnostics with capability to simulate many of the failure mechanisms. However, there are possibilities to deliberately corrupt ECC data to force errors on Flash ECC or RAM ECC or to force parity errors in the peripherals, but there are no possibilities to force bus, CPU, or hard faults that I am aware of.

    I am forwarding your post to one of our safety/architecture experts who might have some ideas or can give a more definitive answer.

  • 0
    TI__Mastermind 23000 points

    Hi Mat,

    If you are limiting to only the Cortex M3 CPU based abort handlers, this is fairly easy in most cases.  From the ARM v7M Architecture Manual (DDI0403D):

    • Usage Fault
      • Execute an undefined instruction
      • Attempt to enter invalid (ARM) state on instruction execution 
      • Attempt to access an unavailable coprocessor
      • Unaligned fetch (if configured)
      • Divide by zero (if configured)
    • Hard Fault
      • Disable the Usage Fault handler and generate a Usage Fault - it will auto-escalate to Hard Fault
    • MemManage
      • Program MPU to block access to a memory location, then attempt to access the location
    • BusFault
      • Attempt to access an invalid address
    • NMI
      • Configure an interrupt in VIM with NMI response, such as an RTI timer interrupt.  Generate the RTI timer interrupt (or other peripheral interrupt)

    I think that should cover the ones you would typically be interested in handling.

    Regards,

    Karl