CCS/MSP430FR2433: CCS keeps breaking at NOP in mult16_f5hw.asm

Hi Rob,
This sounds like the same issue discussed in the below thread:
e2e.ti.com/.../566673

It doesn't look like this thread was fully resolved. I will move this thread to the MSP forum where the experts there can continue to help you.

Thanks
ki

Hi Rob,

Thanks for bringing this issue to our attention. In order to better determine what is causing this, I'd like to understand if there is a specific execution sequence that is causing the problem.

- Do you hit the phantom breakpoint right at the start of the debug session, or after some period of time? Is is consistent and repeatable (happening always and within the same amount of time after start-of-execution), or more random in occurence?

- Is your program modular enough that you can disable portions of the software one at a time to see if the issue goes away, and then we can build back up until we find the component that is causing it?

Regards,
Walter

One more question- Are you transitioning between power modes as well? (i.e. active mode to LPM's back to active mode)?

Hi Walter,

Thank you for your response! Please find my responses to your questions below.

Thank you,
Rob

- Do you hit the phantom breakpoint right at the start of the debug session, or after some period of time? Is is consistent and repeatable (happening always and within the same amount of time after start-of-execution), or more random in occurence?

(ROB) It's random on occurrence, but almost always happens if I give it enough time. Stepping through the phantom breakpoint resumes execution normally.

- Is your program modular enough that you can disable portions of the software one at a time to see if the issue goes away, and then we can build back up until we find the component that is causing it?

(ROB) Yes, I'll experiment with doing this, but because the phantom breakpoint is random in nature it will be difficult to figure out if what I've excluded has solved the issue.

One more question- Are you transitioning between power modes as well? (i.e. active mode to LPM's back to active mode)?

(ROB) I am not yet using any of the low power modes.

Hi Walter,

I have an update. The phantom breakpoint is hitting before interrupts are even enabled! It's reliably hitting while I'm initializing my 'GPIO helper' driver callbacks. See the snippet below:

uint16_t i = 0;
uint16_t j = 0;

for(i = 0; i < GPIO_NUM_PORTS; i++)
{
  for(j = 0; j < GPIO_NUM_PINS; j++)
  {
    pinConfig[i][j].callback = NULL;
  }
}

Here's the callback definition:

typedef void (*gpio_helper_int_f)(gpio_port_t port, gpio_pin_t pin);

Looks like an indexing issue. Is pinConfig[][] large enough?

Hi Keith,

Yup. Here's the definition:

typedef struct
{
  gpio_edge_t edge;
  gpio_helper_int_f callback;
} gpio_pin_config_t;

static gpio_pin_config_t pinConfig[GPIO_NUM_PORTS][GPIO_NUM_PINS];

Additionally, I just power cycled everything and the phantom breakpoint is no longer halting this line of code.

Hi Rob,

I am working on a setup to reproduce your issue for analysis. When you see this issue, do you have any real/intentional breakpoints set at other locations (besides the phantom location where it gets stuck), or doe the issue occur when you have no breakpoints set at all?

Thanks,
Walter

Hi Walter,

No breakpoints. I originally thought that the phantom breakpoint might be from a 'hidden' breakpoint so I explicitly disabled all breakpoints. The issue still presented itself.

-Rob