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.

CCS/MSP430FR5969: CCS breaks at NOP in mult16_f5hw.asm at 16MHz

Part Number: MSP430FR5969

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.

  • Here's the mult16_f5hw.asm code where this phantom breakpoint occurs:

    __mpyi_f5hw:  .asmfunc  stack_usage(2 + RETADDRSZ)
    	PUSH.W	SR			; Save current interrupt state
    	DINT				; Disable interrupts
    	NOP				; Account for latency
    	MOV.W	OP1,&MPY_OP1		; Load operand 1 into multiplier
    	MOV.W	OP2,&MPY_OP2		; Load operand 2 which triggers MPY
    	MOV.W	&RESULT, R12		; Move result into return register
        .if $DEFINED(__LARGE_CODE_MODEL__)
    	POP.W  SR
            NOP                             ; CPU19 Compatibility    <<<<====== PHANTOM BKPT HERE
            RETA
        .else
    	RETI
        .endif
    	.endasmfunc

  • John Wygonski said:
    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.

    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?

    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.

  • Thanks for the reply.

    Yes, my code runs with 1 FRAM wait state when MCLK = 16 MHz, and I checked FRCTL0 register value to verify.

  • You say that you are not executing a multiply, does that mean that you have verified that the compiler hasn't generated one or simply that you didn't code one explicitly?

    You might want to examine the stack to see how you got to that multiply routine.

  • 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?

  • John Wygonski said:
    I really would like to know why CPU execution stops here in the debugger only when running at 16MHz, and not at 8MHz?

    Can you open the CCS Scripting Console and execute the following command:

    eval("DEBUG_DumpBreakpoints()")

    That will display in the CCS debugger Console which breakspoints are set.

  • Here's the CCS Scripting Console output:

    Initializing ... (Completed)
    
    js:> eval("DEBUG_DumpBreakpoints()")
    0
    js:> 

    Appears to be indicating no breakpoints were set?   Matches what the Breakpoints window indicated.    For what it's worth I tried to find any "Break on ..." type settings in the Debug area of the project's properties, but came up empty.

  • John Wygonski said:
    Here's the CCS Scripting Console output:

    The output appears in the CCS "Console" window, not the "Scripting Console" window. E.g.:

  • Sorry, I didn't realize that.   So I ran until the debugger stopped on aforementioned "phantom" breakpoint, excuted the scripting console command, and captured the Console output:

    MSP430: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 4
    MSP430: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 4
    MSP430: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: Enabled: 0
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: Disabled: 4
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$IO$$"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Process CIO
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$IOE$$"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Process CIO
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Type: Simple
    MSP430: Breakpoint Manager Dump: 			Action: Halt Target
    MSP430: Breakpoint Manager Dump: 			Trigger 0: Memory Address Bus
    MSP430: Breakpoint Manager Dump: 				Location: "C$$EXIT" (0x6404)
    MSP430: Breakpoint Manager Dump: 				Mask: 1048575
    MSP430: Breakpoint Manager Dump: 				Operator: ==
    MSP430: Breakpoint Manager Dump: 				Access: Instruction fetch
    MSP430: Breakpoint Manager Dump: 			Trigger 1: None
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Terminate Program Execution
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$EXITE"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Terminate Program Execution
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    
    

  • John Wygonski said:
    So I ran until the debugger stopped on aforementioned "phantom" breakpoint, excuted the scripting console command, and captured the Console output

    OK, nothing in the output shows a breakpoint specifically set in mult16_f5hw.asm.

    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.

  • Thanks for your help and especially for pointing out the errata.   Regarding your reply, I would need to spend some time on #1 and #2--my code is for a client and is proprietary, so it would take a bit to come up with a simple program that demonstrates.

    In particular, #3 the FR5969 errata relating to EEM is a very likely candidate because:

    1.  The issue is not specific to my code, ans others have reported this *exact* issue previously with no posted resolution (see the posts I referenced in my original post.

    2.  My issue only occurs in debug mode at 16 MHz where 1 FRAM wait state, which matches the symptoms described in the errata.

    Since there is no workaround listed in that erratum, perhaps the issue can be "resolved" after upper Tier reply, so that others posting as I did will become aware of your finding.

    Thanks so much for help with getting to the point where I understand why it's occurring.

  • There are some things I don't understand about this EEM errata:
    
    1) The documentation for the multiplier says nothing about wait states. Or any interaction with FRAM wait states. Which shouldn't happen because  the FRAM controller is between FRAM and the data/address buses.
    
    2) The EEM description of triggers says nothing about devices providing them. Memory and CPU register access (if configured) yes, random peripheral, no.
    
    3) If it really is the multiplier triggering this breakpoint, why does execution stop well after the result was read from the multiplier? It would make more sense if execution stopped when the second operand was written.
    
    
    I use the GNU tools rather than CCS. I built a really simple program in assembly to enable 1 FRAM wait state then exercise the multiplier. Using mspdebug I never had this problem. (I set an early breakpoint and an unreachable one.) I even tried varying the alignment of the multiplier instructions to see if cache alignment was involved. Then I bumped MCLK up to 16MHz.
    
    
    
    (Looking at the previous thread for the FR2433 I have to wonder why the compiler/user is using large mode on a device with just 16KB of FRAM.)
    
  • David Schultz36 said:
    3) If it really is the multiplier triggering this breakpoint, why does execution stop well after the result was read from the multiplier? It would make more sense if execution stopped when the second operand was written.

    As noted in Compiler/MSP430FR5959: During debugging software breaks in MULT16_F5HW.ASM the issue may not be the multiplier, but rather that use of the multiplier is protected by disabling interrupts and then restoring the original interrupt enable state.

  • I considered that and I tried it both with and without the interrupt disable code.

    ; -*-asm-*-    set emacs asm-mode
    	;; Simple program to test the EEM23 errata. It enables 1 wait state
    	;; in the FRAM controller and increases the clock to 16MHz.
    	;; Then enters an infinite loop calling a subroutine that
    	;; exercises the multiplier.
    	;; I set breakpoints just before loop and at loop2. loop2 is
    	;; unreachable.
    
    #include <msp430.h>
    	.text
    	.func sys_init
    sys_init:
    	mov.w	#WDTPW|WDTHOLD,&WDTCTL ;disable watchdog
    	mov	#__stack,r1
    	
    	;; Unlock FRAM control register access and set 1 wait state
    	mov	#FWPW|NACCESS_1,&FRCTL0
    	clr.b	&FRCTL0_H		   ;disable FRAM acccess
    	
    	mov     #CSKEY,&CSCTL0 ; unlock CS registers
            mov.w   #DCORSEL|DCOFSEL_4,&CSCTL1 ; set DCO to 16MHz
            ;;  Set ACLK = XT1; MCLK = DCO  
            mov.w   #SELA__LFXTCLK+SELS__DCOCLK+SELM__DCOCLK,&CSCTL2
            ;; SMCLK is DCO/2 or 8MHz, MCLK is DCO/1
            mov     #DIVA__1|DIVM__1|DIVS__2,&CSCTL3
    	eint
    	nop
    
    loop:	calla	#hwmult
    	jmp	loop
    loop2:	jmp	loop2
    	
    hwmult:
    	push	SR
    	DINT
    	nop
    	nop			; extra nops to fiddle with cache 
    	nop			; alignment
    	nop
    	
    	mov	r14,&MPY
    	mov	r15,&OP2	; triggers multiply operation
    	
    	mov	&RESLO,r14	; read result
    	mov	&RESHI,r15
    	pop	SR
    	nop
    	reta
    
            .section .resetvec,"ax",@progbits
            .word   sys_init
    
    	.end
    	
    

  • David Schultz36 said:
    I built a really simple program in assembly to enable 1 FRAM wait state then exercise the multiplier. Using mspdebug I never had this problem. (I set an early breakpoint and an unreachable one.) I even tried varying the alignment of the multiplier instructions to see if cache alignment was involved. Then I bumped MCLK up to 16MHz.

    Using TI MSP430 compiler v18.12.3 I tried re-creating the problem with:

    a. MSP430FR5969 set with MCLK of 16 MHz and 1 FRAM wait state.

    b. Main function spins in a loop performing a uint16_t multiply which calls the __mspabi_mpyi_f5hw RTS function.

    c. Timer0_A0 interrupt every 500 clocks.

    The main function and interrupt toggle a different LED so can tell the program is still running. I have been unable to re-create the problem of the phantom breakpoint. Also tried adjust the start offsets in the FRAM memory region one word at a time to change the cache alignment, but that didn't cause a phantom interrupt.

    The 1 FRAM wait state is having an effect, since if leave the MCLK at 16 MHz but leave the FRCTL0 at the default of zero wait state the program continuously resets.

  • Hi John,

    As you described, this problem will only occur in Debug mode, is normal in the case of free run, thus the root cause of the problem is EEM23 as described by . Since this bug does not affect the normal use of the product, we have not list workaround in that erratum.

    Thanks.

    Best Regards

    Johnson

**Attention** This is a public forum