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/MSP-FET: Using MSP-FET to debug MSP432 project using TImerA breaks ability to step through code

Part Number: MSP-FET

Tool/software: Code Composer Studio

Hi all,

I've been in the process of making edits to my current MSP432 code for our PCB. This code ran perfectly fine on the red Eval board. However, on the MSP-FET we use for our PCB designs, when I step through the code, immediately after I pass over the line to enable either of the TimerA interrupts the code will immediately step into the ISR for the TimerA and will go in and out of it forever. When I run to the next breakpoint, it will do that no problem, but go back into that interrupt when I step in again.

I've tried to solve this problem with multiple computers, MSP-FET's, workspaces, and using CCSv6 vs. CCSv7 but I've concluded this is an error with the MSP-FET debugger. The code works as it should if I run to breakpoints, or if I run it on the Eval board that has the XDS110 debugger, but as of now, I cannot use the MSP-FET's to step through projects with the TimerA module using ISR's.

I can get around this for now using the Systick module which isn't giving me these problems, but I'd prefer to use the TimerA module with ISR's in the future. 

Thanks,

  • Yes I am. It does the same thing without the MSP-FET-432 ADPTR.

    Thanks,
  • Hi,


    your TimerA clock is running in the background while you are single stepping through the code.

    In order to avoid the behavior you are seeing, you need to write to the SYS_PERIHALT_CTL register in SYSCTL (See Technical Reference Manual for details).

    The easiest way to make it work, is to use the built-in functionality in CCS. While you are in the debug session perform the following steps:

    • Scripts -> MSP432 Debug Clock Control
    • Freeze TimerA module

    Which TimerA module you need to select, depends on your target code. For example "Freeze_T16_0" halts the TimerA0 module.

    Thanks,

    Bob

  • This fixes it nicely, thanks!

    I also saw the register it was changing and added a statement near the top of main.c that says:

    SYSCTL->PERIHALT_CTL |= SYSCTL_PERIHALT_CTL_HALT_T16_0;

    which ensures this gets suppressed every time the code runs. Its working now, but do you see anyway this could hurt me in the future?

    And also, would suppressing this ISR do any harmful effects when its running while not Debugging through the code? 

    Thanks,

  • Writing to the peripheral halt register only freezes the module if the CPU is halted.

    So if you aren't debugging through code, I guess the CPU will always run continuously (unless your code makes the CPU halt).

    To be precise, you aren't suppressing the ISR, you are halting the module so the TimerA doesn't continue to run while the CPU is halted.
    That means if you single step long enough, you will eventually step into the ISR.

  • I found the same trouble of MSP-FET. You can see the Properties->Debug->Program/Memory load options->Disable interrupts-> When source stepping disable is checked. I wonder this setting is not effective for MSP-FET while XDS110 is effective. XDS110 have not this trouble, but if you un-check this setting of XDS110, XDS110 will cause the same trouble.

    I found a workaround about this trouble for MSP-FET. When stepping, clear NVIC interrupt enable bit for IRQn with writing 1 into ICERn register and execute 1 step resulting in 0 in ISERn register. To re-enable that again, writing 1 into ISERn register and execute 1 step resulting in 1 in ISERn register. I attached a case of disabling TA0, IRQn=8.

  • Thanks for the reply Kazuo,

    I'm trying this now. I'm finding the method in my previous post and Bob's post only worked randomly, and after a while, it seemed to bring back the problems with these interrupts triggering.

    Do you think I should turn all of the ICER0/ICER1 bits off at the beginning of the program when debugging?

    Its good to know someone else found the same. I still don't believe that Debug setting does anything for the MSP-FET either.

    Thanks,
  • Hello Lunatic911,
    When you want step debugging, set a break point at the start point for step debugging and see interrupt enable bits in ISERn, rewrite all on bits in ICERn. Then all interrupts are disabled at the moment. but pending interrupts are executed. I think you can use XDS110 emulator on LaunchPad rev-C or B board in safety. Please refer MSP-EXP432P401R UG slau597b, 2.3.4 Using the XDS110-ET Debug Probe With a Different Target.
    Best Regards,
    Kazuo Yamauchi

  • Sorry for getting back to this so late,

    Just wanted to let you know that I took your advice and used the XDS110 emulator on the LaunchPad and sent it to the MSPFET-ADPTR and then to an adapter cable I need that connected to the other side of MSPFET-ADPTR. I've been able to debug on my PCB no problem since then.

    Thanks for the help. But TI should be aware there's a pretty substantial bug with the MSP-FET and MSP432's. The earlier fixes mentioned above were only randomly temporary fixes. I'll be using the XDS110 emulator on the Eval board until there is a fix for the MSP-FET.

    Thanks again,
  • Hello Lunatic911,

     

    I found how to stop interrupt briefly at step debugging with MSP-FET and CCSv7_1.

    As bellow, Clock control Script can Freeze (disable interrupt) and Continue (enable) all modules well.

     

    I’ve confirmed these behaviors with example msp432p401r_ta0_01.c.

    If this can resolve your issue, please click Verify Answer.

**Attention** This is a public forum