MSP430G2553 debug and LFXT

Hello Pedro,

So you tried the line _BIS_SR(OSCOFF); without effect? In this instance make sure you are not sourcing MCLK or SMCLK with LFXT1. You can also try changing the Debug Interrupt settings under Project Properties (Right click on Project -> Properties -> Debug -> Program/Memory Load Options -> Disable interrupts).

The MSP-EXP430G2 LaunchPad has an on-board eZ-FET lite whereas the MSP-FET is a newer design and utilizes EnergyTrace technology. Quality is most likely the same but higher speeds can be achieved with the MSP-FET. You can alter the JTAG/SBW speed by selecting the .ccxml file (project main path -> targetConfigs folder).

Regards,
Ryan

Hi Ryan, thanks for your answer, i'll increase the speed in the ccxml file.

I'll get an MSP-FET and try out how much faster it is. The energytrace is for sure a great feature.

About the oscillator, it's not that I can't disable it with code, that I can do. What I want to achieve is that when I set a breakpoint somewhere, and the MCU hits the breakpoint and halts, I would like that the clock control settings in the debugger options are followed, and the indicated clocks are stopped. Why do I say this?, because now, I have configured to stop all the clock sources, even LFXT when a breakpoint is hit, but then LFXT doesn't stop, and as a result of that, the timers keep running. That is my problem.

Best regards,
Pedro

I think you want to disable Interrupt call’s while stepping through the program, this can also be disabled in the properties.

Hi Leo,

Thanks for your answer. But no, that is not what I'm trying. What you say is very useful indeed, and I have it disabled because otherwise debugging is not easy if you have interrupts. But that's not the problem I'm having now. Let's see if I can explain it more clearly, because I think it might not be clear.

I just want that when I set a breakpoint, and the MCU stops at that breakpoint, everything in the MCU is stopped, specifically, all clocks.

To obtain this, I do the following; I go to Tools -> Debugger Options -> MSP430 Debugger Options, and in the "Clock Control" section, under "Stop the following clocks on emulation halt:" I select all Clocks, ACLK, SMCLK, and TACLK.

But, what I see later is that when a breakpoint is hit, ACLK, doesn't stop even though it is configured to stop. That is my problem.

Best regards,
Pedro

Ok now it’s more clear what you want to do. I debugged a lot but never had the need to stop any clock, so I don’t have experience with this, hopefully Ryan can explain more.

Pedro,

I was able to confirm your dilemma using an o-scope and a basic code example outputting ACLK onto pin 1.0 of a MSP430G2553 device, even though ACLK is supposed to stop during an emulation halt based on the settings from Tools -> Debugger Options -> MSP430 Debugger Options it still keeps running. I am currently submitting a CCS bug to further investigate this matter.

Regards,
Ryan

>I just want that when I set a breakpoint, and the MCU stops at that breakpoint, everything in the MCU is stopped, specifically, all clocks.
What's more interesting - why you need to stop clocks? What kind of debugging you are doing? I can agree to Leo - I never needed clocks to be stopped during debug. Usually I debug timing with oscilloscope and debug/service pins, sometimes simple helper debug code is enough.

Ryan, thanks a lot for the effort, it's good to confirm that this is a bug.

Ilmars, I don't have a lot of experience with MSP430's, but I do have with other microcontrollers. And most MCUs support this, as I'm sure was also intended to work on the G2553.

I agree with you that to debug the timing, a couple of debug pins and a scope or logic analyzer is the best thing, but only if the timing code you are trying to debug is really simple.

But now that I am doing some more complex code involving a kind of mesh radio network, where I need synchronization, very low power, and real-time system behaviour with a fast response to certain events, I need to do more complex debugging and the timing is the center of all of this. So things are at a point where it is more complex that what debug pins can deal with (although that is what I am mainly using).

One thing I am doing, is to manually place timer stop code the line before the breakpoint, so when the breakpoint is hit, at least the timer is stopped and I can do some debugging. But it is not the most convenient because I need to rebuild if I want to change the breakpoint. And some failures take some minutes to reproduce, so it is a PITA at the moment.

But at least, I have to say that it is very nice to have a resource like this one to share these problems with other people, and with involved people like you guys and Ryan that give great support.

>I need to do more complex debugging and the timing is the center of all of this.
Ok, good. I just wanted to be sure that you know other ways of timing debug. Just curious - does IAR properly stop clocks?

Pedro,

An internal investigation resulted in the following answer:

The clock on the port pin could not be stopped because the ACLKr (running) is directly connected to the port. Only the ACLK module clock is stopped during debug mode. If you were to try sourcing a timer with the ACLK and check if the timer is counting up during a debug halt state, when ACLK stop is selected in the debugger, you would find that TA0R does not keep incrementing hence the ACLK module clock has been stopped as expected. The ACLKr, however, will continue and therefore be output on the pin.

Regards,
Ryan

Hi Ryan,

Thanks for your answer. So if I understood you right, you mean that the clock signal will always be present on the pin, but internally the signal has no effect, so a timer that would be fed by ACLK would not continue to increment.

So, I am not measuring the IO pin, I imagine there is the clock signal there of course. What I am observing is that a timer A that is sourced by ACLK DOES keep running during halt, in spite of the debugger being configured to stop ACLK, and also to stop TACLK. So if I halt and press the "refresh" button in the "registers" window, I see that TA1R is still running. Indicating that, internally, the clock is still feeding TA, an against what is to be expected by the "clock control" configuration.

Hi Ryan,

This topic seems to have been left forgotten, it is still causing problems, and I am still seeing the behaviour that I described on my last reply on Jun 8, 2015. Which basically says that it is not only an effect on the output pin, but also can be seen internally in the register values, and especially in the interrupt triggering.

Any news about this?

Best regards,

Pedro,

I don't think we have ever confirmed this: are you using CCS or IAR? Can you provide the exact version you are using. My expertise is limited to the CCS debugger which I find operates as expected under the given conditions. In the MSP430 Debugger Options I have ensured that ACLK, SMCLK, and TACLK are stopped during an emulation halt.

Regards,
Ryan

Hi Ryan,

I have CCS, and this has been happening to me on all versions since one year ago.

I have also configured in the debugger options to stop all three clocks during emulation halt. However, if I hit a breakpoint, and I refresh a timer register, I see that the timer is still running. In fact, I still get interrupts generated by the timer. If all clocks are stopped, the timer should always show the same value. I'll try to see the exact version when I get to my development machine.

Best regards,

Pedro

Pedro,

This question might be better serviced in the Code Composer Studio Forum since their experts more closely work with the debugger interface. Please be sure to provide the CCS version you are using.

Regards,
Ryan