• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 725 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.

Lockstep Test - CCM in error forcing mode

Stelios Gan
Intellectual 450 points

Hello people,

I am trying to test the functionality of CCM in error forcing mode (initially). I am trying to use the code of Safety Demos, but an ESM Interrupt does not seem to be triggered. The steps that I follow are:

  1. initialize the esm.
  2. set the CCM in error forcing mode
  3. wait for ESM interrupt flag 

In the step no. 3 it looks that it stucks. It does not trigger an ESM interrupt. I use the functions of the safety demo (CCM_R4_Compare, swi_enable_fiq_irq()) and the flag ESM_High_Int_Flag that is used there. What am I missing? I know that the CCM does not respond in debug mode. I do not use any breakpoints. 

I attach my project for a clear view. I will be really grateful for any suggestion.

Regards,
Stelios2604.LockstepTest.zip

  • 0
    TI__Guru 59540 points
    Hello Stelios,

    Please note that the CCMR4 is disabled when in debug mode and not error will be generated regardless of what mode the CCMR4 is placed in. The CCMR4 will then be disabled until the next power on reset (nPORRST assertion).

    This makes it very difficult to debug with the IDE. One method is to program your test code, let it run without the debugger and then connect and check for the ocurrence (ESM should have latched the error unless your code clears it). If you need for your code to clear it, you might be able to set a flag on a static variable that could be checked upon connect to see that the error occurred.

    Also, reviewing your code, I would not put the call to the CCM_R4_Compare in a tight while(1) loop as you may put the device in a tight loop of CCM errors/interrupts. This may result in issues connecting to and programming the device (i.e., brick it).