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.

TMS320F28075: WDCR[WDCHK] setting and ILLEGAL_ISR

Part Number: TMS320F28075
Other Parts Discussed in Thread: C2000WARE

Dear all,

We reset the DSP with watchdog module. Stepping the code, we see that just after the line "WDCR[WDCHK] = 0", the execution jumps to "ILLEGAL_ISR (ITRAP0)".

Of course, the DSP is reset but, is this the normal behavior?

Best regards and thank you.

Paloma

  • Hi,

    ILLEGAL_ISR happening after reset or before reset and then reset happens. Also can you share the snapshot of the code where you are setting WDCR[WDCHK] = 0. Basically want to see what code you have after WDCR[WDCHK] = 0.

    Regards,

    Vivek Singh

  • Dear Vivek Singh,

    This is the code sniped

    void ResetDSPControl( void )
    {
        volatile Uint16 temp;
        EALLOW;
        //Grab the clock config so we don't clobber it
       // WdRegs.SCSR.bit.WDENINT = 1;
        temp = WdRegs.WDCR.all & 0x0007;
        WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x5, enabling watchdog
       // WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x4, enabling watchdog and forcing reset
        EDIS;
    
    }

    Best regards, 

    Paloma

  • I am assuming you are getting ITRAP when CPU start executing after WD reset. If that is correct then please make sure you are not running the code from RAM because on this device all the RAMs are cleared on WD reset. You need to have code in flash for this to work.

    Regards,

    Vivek Singh

  • Hello,

    I am not sure that it is the reason.

    This is the execution in assembly:

     

    When PC is in 0x8dab4 (EDIS;), stepping into, execution jumps directly to the ILLEGAL_ISR:

     

    I don't think that RAM memory is involved.

    Thank you.

    Best regards, 

    Paloma

  • Have you tried putting the code in flash and then try? If not, please try that and let us know if you still face the same issue.

    Regards,

    Vivek Singh

  • Hello, I am not sure if I understand you.

    The code is already in Flash. The addresses shown in the screenshot of the assembly I sent you, are all in flash. And that’s the actual code.

    Do I have to check another thing?

    Paloma

  • Hi Paloma,

    I see the address as flash but the values at those locations are all 0x0 which is confusing. Are you securing the device ?

    Regards,

    Vivek Singh

  • We are not using CSM module, all CSMKEYs are = 0xFFFFFFFF.

    I have executed the code again and, I don't know what happened before but, ILLEGAL_ISR in assembly now looks like this:

    I have exceuted the code several times.

    Paloma

  • Ok. Is it possible for you to attach sample CCS project with this which I can use ?

    Regards,

    Vivek Singh

  • Sorry, but I can't share the project. Is there any TI example I could use to know if the problem is in our hardware?

  • Yes, you can find a Watchdog example (device_support\f2807x\examples\cpu1\watchdog) in C2000Ware.

    Regards,

    Vivek Singh

  • Hello, 

    I don't want to use that example because it runs in RAM memory.

    Instead, I have imported to IDE: flash_programming_cpu01

    After IniFlash call I have copy paste:

       asm(" EALLOW");     // Enable EALLOW protected register access
        WdRegs.WDCR.all = 0x002F;
        WdRegs.SCSR.all = 0x0000;
        asm(" EDIS");
    
        DINT;       /* disable interrupts */
        EALLOW;
        WdRegs.SCSR.all = 1;            /* WD generates a reset, and WDDIS can be modified */
        WdRegs.WDCR.all = 0x002F;       /* enable the WatchDog (should be already enabled) */
        WdRegs.WDCR.all = 0x0000;       /* force a reset by writing WDCHK != 101 */
        EDIS;
        EINT;

    And same problem appears.

    Best regards, 

    Paloma

  • hello, any information about this?

    Best regards, 

    Paloma

  • Hi,

    I used your code but not able to reproduce this issue. I'll try flash_programming_cpu01 code tomorrow and see if I can re-produce this issue.

    Regards,

    Vivek Singh

  • Hi,

    I tried flash_programming_cpu01 example with exact same code what you have for WD reset and do not see any issue. After reset, I see code jumps to main again (no ITRAP). What hardware you are using for this test ?

    Regards,

    Vivek Singh

  • It is a custom board, and it happens in all boards. Could it be a hardware design problem?

    Just in case there is a misunderstanding, I attached the modified example that causes us the TRAP and a video that shows when the code execution steps into ILLEGAL_ISR.

    Thank you.

    Paloma

    ILL_ISR.zip

  • Very difficult to say. If you have TI controlCARD then try there. Also if you can zip the project you are trying then I can try that on my setup here.

    Vivek Singh

  • Hello,

    I looked for a TI controlCARD but we haven’t. I tried the project in a different design custom board and it behaves the same.

    I already attached the modified TI example project in a previous post, I attached again in case there was a problem with it. Could you try the project in your TI board? In main function, I would like you to set a breakpoint line 162 and step into until line 170 and see what happens when code steps into (F5) line 171 and line 172. In the video I attached in the previous post, it can be seen that the code goes to the ILLEGAL_ISR, Could you send me a video showing how it behaves in your board? I beginning to think that the step to the ILLEGAL_ISR is the normal behavior.

    Thank you very much and best regards,

    Paloma

    0143.ILL_ISR.zip

  • I tried this project and do not see any issue. I step through the code and after reset it halts inside BOOTROM. After I run it halts at line 162 in code (where I have set the break point). So no issue. Below is the step I followed.

    • Load the code.
    • Write 0x0B5A @0xD00 via CCS memory watch window (that is boot to flash in emulation mode).
    • Set a breakpoint @line #162
    • Run
    • CPU halts as line #162. Now Step through rest of the code.

    After line #170 CPU get reset and halts inside BOOTROM. Again hit run and now CPU again halts at line #162.

    This is how it should work on your board as well.

    Regards,

    Vivek Singh

  • Hello,

    I try the Project in the TI controlCard for F28075 tmdxdoc28075 and after forcing WD reset, DSP jumps to ILLEGAL_ISR, and of course, with the for(; ; ) instruction within the ILLEGAL_ISR, the DSP is reset.

    Vivek Singh said:
    After line #170 CPU get reset and halts inside BOOTROM. Again hit run and now CPU again halts at line #162.

    But, does it go through the ILLEGAL_ISR? In our execution, when the code reaches line #170, the CPU goes to the ILLEGAL_ISR. Then I run the code, and of course the DSP is reset and hits again breakpoint in line #162.

    It seems that the fact of writing in WDCR = 0x0 causes the ILLEGAL_ISR.

    Thank you.

    Paloma

  • No, I don't see it's going to ILLEGAL ISR on my setup. It halts inside BOOTROM.

    Regards,

    Vivek Singh