MSP430FR2476: MSP430: Debugger halts with no breakpoint set

Hello,

Wayne Michaelson said:

The firmware was running, but would intermittently stop at a specific line in a routine as if it was on a breakpoint.

Which source file and line number does it halt on?

Thanks

ki

It starts in main.c, calling a routine in hal.c, into another routine, and into a third routine. It would stop in the first executable line of the third routine in hal.c . The breakpoint window was blank so I did not capture that.

Wayne Michaelson said:

It starts in main.c, calling a routine in hal.c, into another routine, and into a third routine. It would stop in the first executable line of the third routine in hal.c .

Is this location consistent every time?

Can you use the DEBUG_DumpBreakpoints GEL call in the scripting console and copy and paste the output to a text file and post it to this thread?

See the below post for more details on this:

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/479091/remove-hw-breakpoint-on-ccs-v5/1733180#1733180

Also, please enable debug server logging and reproduce the issue. Please only turn on logging right before running the program. AFter the unexpected halt occurs, disable logging, close CCS, zip the the log and attach it to this thread.

https://software-dl.ti.com/ccs/esd/documents/ccs_diagnostic-logs.html

Thanks

ki

It would consistently stop at the same line, but not always the first time through the routine. In attempting to get a workaround for this, I edited an earlier part of the hal.c code and then it worked. I still think there is a ghost breakpoint in there, but it is now missing it. I do not have easy access to the system that was failing, but when I get a chance I will try dumping the data. This is running on 5 different systems, and each will have used different breakpoints in the past.

I cannot reproduce the symptom at this time. I did the eval("DEBUG_DumpBreakpoints()") in the Scripting Console, but it only showed the default 4, while another system that has two real breakpoints set showed 6 with the two real breakpoints at the expected lines. Having this command will help in the future if it occurs again.

Wayne Michaelson said:

The firmware was running, but would intermittently stop at a specific line in a routine as if it was on a breakpoint.

What is the processor frequency (MCLK) and are wait states enabled?

Due to errata EEM23 have seem some MSP430 FRAM devices stop at the wrong address - see Could CCS apply a work-around for MSP430 FRAM devices errata EEM23 to allow CIO to be used without the target halting in trgmsg.c? and MSP430FR2675: How to enable printf output to console in CCS 10?

It is running at 16MHz and the wait states are enabled. I do edit the files in an external editor and then run CCS to compile and have seen the breakpoints move to different lines. Another option I did not think of at the time of the halt was to add a breakpoint followed by a remove all breakpoints. Remove all is not available when none are showing.

Wayne Michaelson said:

It is running at 16MHz and the wait states are enabled

I wonder if your issue is related to the behavior Walter mentions in his post below:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/685882/ccs-msp430fr2433-ccs-keeps-breaking-at-nop-in-mult16_f5hw-asm/2614289#2614289