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

Rob Oppen78

Part Number: MSP430FR2433
Other Parts Discussed in Thread: MSP-FET

Tool/software: Code Composer Studio

See the attached screenshot. CCS keeps hitting a phantom breakpoint in __mpyi_f5hw in mult16_f5hw.asm. This is making debugging impossible. I'm using CCS version 8.0.0.1, the new version of the MSP-FET using Spy-Bi-Wire and a MSP430FR2433 on our own development board.

over 7 years ago

0 Ki over 7 years ago

TI__Guru**** 451541 points

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

0 Walter Schnoor over 7 years ago in reply to Ki

TI__Expert 7530 points

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

0 Walter Schnoor over 7 years ago in reply to Walter Schnoor

TI__Expert 7530 points

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

0 Rob Oppen78 over 7 years ago in reply to Walter Schnoor

Prodigy 170 points

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.

0 Rob Oppen78 over 7 years ago in reply to Rob Oppen78

Prodigy 170 points

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);

0 Keith Barkley over 7 years ago in reply to Rob Oppen78

Guru 41995 points

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

0 Rob Oppen78 over 7 years ago in reply to Keith Barkley

Prodigy 170 points

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.

0 Walter Schnoor over 7 years ago in reply to Rob Oppen78

TI__Expert 7530 points

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

0 Rob Oppen78 over 7 years ago in reply to Walter Schnoor

Prodigy 170 points

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

0 Walter Schnoor over 7 years ago in reply to Rob Oppen78

TI__Expert 7530 points

Hi Rob,

Are you still seeing issues here?

If so, are you running at >8 MHz execution speed? We've been digging into this debug behavior and have seen that this debug halt seems to occur at 16 MHz but not at 8 MHz in some of our testing. I would be interested to know if it goes away if you run at 8 MHz.

Walter

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

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