• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 1026 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.

How to implement "Illegal operation and instruction trapping" ?

user1411371
Intellectual 990 points
Other Parts Discussed in Thread: HALCOGEN

I read <Cortex-R4 and Cortex R4F Technical Reference Manual> 3.7.6 Undefined instruction

but didn't catch the point of implement

I don't know much about Assembly language and ARM Architecture.

Is there any example code about how to configure Undefined instruction and how to know it trapped a illegal operation ?

  • 0
    TI__Guru 59540 points
    In the TMS570 devices, this will occur as an abort which will trigger an interrupt from the CPU. If you utilize the Halcogen tool to generate your code, there will be a framework to implement the abort handling in the interrupt handler. In this framework, you can define the handler code. If there is no handler code, this type of error will cause an assertion of the nERROR pin which can be flag an critical failure to the "outside world." If paired with the TI TPS65381 PMIC, the nERROR pin can trigger the PMIC to reset the MCU.
  • 0 in reply to Chuck Davenport
    Intellectual 990 points
    I'll check my generated code to find this.
    I saw you said that this handler will use interrupt ?
    We were told not to use intterrupt in our software because of their industry regulations. So can we use this handler ?
  • 0 in reply to Chuck Davenport
    Intellectual 990 points
    Could you tell me where is the code about this allocated ? I just found like "_coreGetInstructionFault_" in generated code.
    Where is the start/enable code of this ?
    Thank you!
  • 0 in reply to user1411371
    TI__Guru 59540 points
    Hello,
    In the Halcogen related code, there should be a file that has the interrupt vectors setup in it. Some of these should be dabort(), pabort(), etc. Unfortunately, I am not at a location to check this fully at this time so these are the only details I can provide at the moment. Note that these are system exception handlers that are triggered by the aborts signaled by the core. These are interrupt based exceptions and I am not aware of how one would work around that fact in a safety system. i.e., polling would only allow periodic checking of the system status flags and would represent a risk from a safety standpoint. i.e., if there is an illegal instruction provided to the CPU, how would you suppose the system would be notified since the CPU would not know what to do with the instruction while the system waits for the flag to be seen? Latency would be excessive.

    I have copied one of our safety/architecture experts on this thread so that they can offer additional insights.
  • 0 in reply to Chuck Davenport
    TI__Guru 68920 points
    Chuck,

    These are exceptions, but not interrupts. They're exceptions that indicate a fault.
    IMO this would not violate any requirement to 'not use' interrupts in the application.
    The fault handler isn't part of the application functionality, and normally would never occur
    unless there is a problem.