- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
CCS/MSP430FR2433: CCS breaks at NOP in mult16_f5hw.asm at 16MHz, and locks outside of debug too.
Tool/software: Code Composer Studio
During debugging with CCS, a phantom breakpoint stops execution at a NOP in mult16_f5hw.asm. However I am not executing any multiply at the time. This is occurring in a mature firmware project that I recently modified to run with MCLK = 16 MHz. Same code with MCLK = 8 MHz does not have this issue, which is exactly the problem reported in this post. and also here. Both of these posts were locked without resolution so I am reopening the question.
Similar to symptoms in the other problem report, the issue may be related to SPI in some way: I had code that failed with SPI peripheral access with MCLK = 16 MHz when using driverlib functions for SPI and clock initialization. My solution was to drop MCLK to 8 MHz and the code has been fine in the field. However if I simply increase MCLK to 16 MHz (after all SPI access is completed) , CCS consistently hits this phantom breakpoint at at a NOP in mult16_f5hw.asm.
I can provide more detail, but I am asking for help in with analyzing this issue.
When the MCLK was increased from 8 MHz to 16 MHz was the number of wait states in the FRCTL0 FRAM Controller Control Register 0 changed from the default of zero to one wait states?John Wygonski said:
Running with a MCLK of 16 MHz and zero FRAM wait states operates the device outside of the datasheet specifications any may lead to undefined operation:
msp430fr59xx_cs_02.c is an example which set one wait state before setting MCLK to 16 MHz.
Here's the stack immediately after loading, which shows that boot code was executed and CPU is stopped at main:
Now I run, and hit the "phantom" breakpoint. Here's the stack:
So next I stepped through my code, and I can see where the _mspabi_mpyi_f5hw() function is getting called:
It's not entirely clear to me why the compiler-produced assembly code puts in this call to __mspabi_mpyi_f5hw, but that's not he primary concern. I really would like to know why CPU execution stops at the NOP in_mspabi_mpyi_f5hw in the debugger only when running at 16MHz, and not at 8MHz?
The output appears in the CCS "Console" window, not the "Scripting Console" window. E.g.:John Wygonski said:Here's the CCS Scripting Console output:
OK, nothing in the output shows a breakpoint specifically set in mult16_f5hw.asm.John Wygonski said:So I ran until the debugger stopped on aforementioned "phantom" breakpoint, excuted the scripting console command, and captured the Console output
Further thoughts:
1. Can you capture the Debug Server Logs as described in CCS Diagnostic Logs and attach them that might give more information on the cause of the problem.
2. Are you able to post an example program which demonstrates the problem?
3. Having looked at the MSP430FR5969 Device Erratasheet there is the following:
Given that the phantom breakpoint occurs when using the FRAM controller with one wait state enabled in the FRCTL0 maybe EEM23 explains the cause. Hopefully a TIer will be able to clarify if this explains the problem.
**Attention** This is a public forum
