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.

CCS/TMS320F28335: cannot get into ISR when debugging

Part Number: TMS320F28335

Tool/software: Code Composer Studio

Hi, 

When I try to debug my ADCINT_ISR with CCS 8.2, it does not stop in a break point within the ISR.

I tried the following:

(1) AdcRegs.ADCTRL1.bit.SUSMOD = 3; which means ADC will stop immediately when a debugger hits a break point.

(2) pEPwmRegs->TBCTL.bit.FREE_SOFT = 0; so that the ePWM will stop as well. I use ePWM to trigger ADC SOC.

(3) I can see the ePWM counter is counting properly, and when CTR = 0, ADC sequence starts and finishes as designed.

(4) I check AdcRegs.ADCTRL2.bit.INT_ENA_SEQ1, IER, and PieCtrlRegs.PIEIER1.bit.INTx6, so that interrupt is enabled.

(5) I run the programme in CCS, I can see the corresponding bits of PIEACK, PIEIFR1 and IFR set, when the ADC sequence finishes.

(6) I read some posts suggesting I need to include the following:

SetDBGIER(IER); // Configure the DBGIER for realtime debug
asm(" CLRC INTM, DBGM"); // Enable global interrupts and realtime debug

in the main file.

When I build the project, it shows an error of "unresolved symbol". It does not recognise SetDBRIER(IER) for some reason.

(7) Then I put

 DINT;
 asm(" PUSH IER");
 asm(" POP DBGIER");
 EINT;
 asm(" CLRC INTM, DBGM");

When it is running, I can see DBGIER = IER = 0x0103 and INTM, DBGM bits of ST1 = 0, which enables the ADCINT (int1.6).

Still it does not stop within the ISR.

(8) I checked values of some variables in ISR. I believe when I am debugging, the ISR is never executed, because some variables never change.

Could anyone help me out? What registers did I forget to set, so that it will run the ISR? What settings/extra command lines do I need to include to allow for debugging? The project is working with hardware, but when I try to debug, it never enters the ISR. Why?

  • It sounds like you've hit all the right settings. You could also try toggling a GPIO in the ISR to see whether or not it's actually running. You can also try a software breakpoint by using __asm(" ESTOP0) in the ISR and see if it stops there. Do you have other ISRs? Do they have this problem?

    Do you have optimization turned on in the compiler?

    Whitney
  • Hi Whitney,

    Thanks for your comments. I am sorry that I found the reason and it is really embarrassing. My colleagues modified the code to allow different ISRs for the same interrupt under different modes. It is actually running in another ISR. I am so sorry. But thanks for your help.

    But still I am quite confused about the DBGIER register. I found that whether or not to include the following in the main file does not make a difference in my case.

    // DINT;
    // asm(" PUSH IER");
    // asm(" POP DBGIER");
    //
    // asm(" CLRC INTM, DBGM");
    // EINT;

    The only explanation I can find about DBGIER is the following from the document. What does it mean? What is DBGIER for? I did not understand the following description.

    What does "the only interrupts that are serviced are time-critical interrupts that are also
    enabled in the IER. " mean?

    Shouldn't it be ".....DBGIER"?

    "The Debug Interrupt Enable Register (DBGIER) is used only when the CPU is halted in real-time
    emulation mode. An interrupt enabled in the DBGIER is defined as a time-critical interrupt. When the CPU
    is halted in real-time mode, the only interrupts that are serviced are time-critical interrupts that are also
    enabled in the IER. If the CPU is running in real-time emulation mode, the standard interrupt-handling
    process is used and the DBGIER is ignored."

  • Glad you were able to find the issue.

    DBGIER enables interrupts to continue to occur during an emulation halt. You only see the effect when debugging in real-time mode in CCS.

    Whitney