This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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?

In MSP430FR2675: How to enable printf output to console in CCS 10? and MSP430FR2355: trying to use CIO on MSP430FR2355EVM?? some users of MSP430 FRAM devices reported that when attempted to use CIO that the target was getting stopped in trgmsg.c rather than the CIO output being reported on the debugger console and the target automatically being resumed.

When repeated the issue:

  • The target was being stopped at an address 8 bytes less than that of the C$$IO$$ symbol.
  • From looking at either the output of eval("DEBUG_DumpBreakpoints()") and the CCS Debug Server log couldn't see an issue with how the breakpoint was being set on the C$$IO$$ symbol.
  • The issue occurred on MSP430 FRAM devices which list errata EEM23.
  • The issues occurred when a non-zero number of FRAM wait states was enabled, and went away when the number of FRAM wait states was changed to zero. I.e. appears related to errata EEM23 rather than a software bug in the CCS debugger.

Would it be possible for the CCS debugger to try and detect if the target has been stopped at a breakpoint just before the C$$IO$$ symbol, and perform the CIO action, to mitigate against the effect of EEM23?

One issue with attempting to mitigate against  against the target being stopped at a different address to that on which a breakpoint has been set is that in the published description of EEM23 isn't clear if the target will always stop at a fixed offset from the address at which the breakpoint has been set:

  • Hello Chester,

    Many thanks for the suggestion here and the investigation in those other threads. I'll be sure to feed this back into CCS and SW teams as a path to investigate in future MSP Debug Stack releases. 

    I'm unsure of the details of EEM23, but my guess it has to do with the wait states causing some uncertainty or undefined states between the interaction of the EEM and the CPU.