MSP430FR5964: Debugger not breakpointing on load

This symptom suggests that the CPU is resetting (repeatedly) in initialization such that it never reaches the first line of main(). When I encounter this I try setting a breakpoint at the reset entry point then step through. The entry point name looks something like "_c_int00_<mumble>" but in a pinch I use "Hard Reset" (toolbar button that looks vaguely like an SOIC chip) to take me there.

One common cause for this is having "too much" data, such that C initialization takes too long and the Watchdog triggers. What sort of "minimal changes" are you making? You can also avoid this (pre-emptively) by defining a function something like "void _system_pre_init(void) {WDTCTL = WDTPW | WDTHOLD; return(1);}"

The MPU can also make this happen, if you don't get it quite right (voice of experience here). Are you using (re-configuring) the MPU?

You referred to "test hardware"; can you describe this? There are custom-board anomalies that can cause this symptom (done that too), but I'm not sure I can enumerate them all.

Bruce.

Thanks for that - it definitely sounds possible, and the addition of additional code and underlying initialisation could explain why the code that is exposed, is impacting the load/launch. More research is required, because I'm not totally convinced, but at worst its given me a place to start. The code changes definitely involve a fair amount of data, and hadn't considered any impact on the standard initialisation code running before I get control. Now onto your other questions;

The test hardware is a custom board that supports the code I was doing the upgrade to. This board design has been running pretty much continuously for around 3 years, and have had no issues running with or without JTAG support. The code that is being altered is the normal logic  running on this hardware, so grabbing another instance of the board was a logical place to start testing. I don't think the problem is there.

On to our "minimal changes" which is where I have to confess all my sins!

About 12 months ago, I was working to understand a peripheral I hadn't used before. Rather than set up a new project in CCS to have a play, I simply grabbed this existing project, and dropped a bit of code into main() immediately following the normal initialisation. This was structured as an infinite loop, literally "while (1) {}" with the test logic nested in the loop. This meant that the normal logic was never triggered. But I neglected to remove this test loop, so when I was adding the new functionality, it was still sitting there. With the new code loaded to the MSP, it launched fine, but of course hung in this loop. So, I backed this test loop out, and the launch promptly never reached the main() breakpoint. I've even gone as far as leaving the test code in, but suppressing the loop (changing the "while true" to "while false") - when true, the code launches fine, when false it never hits the breakpoint at main().

Weird... Starting to wonder if something to do with optimisation could affect the load/launch behaviour. Optimisation should be off (-O0), but optimisation in GCC is a bit of a black box at the best of times. I wouldn't have thought that any optimisation would go as far as identifying unreachable data that never needs initialisation, but stranger things have happened. But I'm guessing this has to be related to something I have added. The new logic is pretty easy to isolate and remove, so my initial strategy is to back that out, get back to a working configuration, and move forward from there.

Thanks for the thoughts - I'll keep you posted!

Andrew