Other Parts Discussed in Thread: MSP-FET, MSP430FR5969
Tool/software: Code Composer Studio
Was using CCS 9.1.0.00010 to attempt to debug why a MSP430FR5969 application stopped responding when left running. After attaching the debugger using a MSP-FET to a device which had stopped responding tried to use the CCS Verify Program operation to check that the program in FRAM was still valid, but got a data verification error at address 0x04400 which is the lowest address in FRAM.
The memory map of the program is such that the lowest FRAM address is used for variables which use #pragma NOINIT to preserve their state across reboots and therefore it is expected the variables in the .TI.noinit section will fail to verify after the program has been set running. The issue is that the CCS Data Verification seems to stop on the first verification failure rather continuing to check other sections.
For this example:
1. Running the cg_xml sectti utility on the generated out file shows that the .TI.noinit section is marked as initialised data in the ELF image:
$ ~/ti/ti-processor-sdk-rtos-am335x-evm-05.01.00.11/cg_xml/utils/ofd6x -x ~/workspace_v9/Cold_Chain_Demo_v1_00/Debug/Cold_Chain_Demo_v1_00.out | ~/ti/ti-processor-sdk-rtos-am335x-evm-05.01.00.11/cg_xml/bin/sectti
Reading from stdin ...
************************************************************
REPORT FOR FILE: /home/mr_halfword/workspace_v9/Cold_Chain_Demo_v1_00/Debug/Cold_Chain_Demo_v1_00.out
************************************************************
Name : Size (dec) Size (hex) Type Load Addr Run Addr
-------------------- : ---------- ---------- ---- ---------- ----------
.TI.noinit : 4643 0x00001223 DATA 0x00004400 0x00004400
.cinit : 746 0x000002ea DATA 0x00005800 0x00005800
.const : 143 0x0000008f DATA 0x00005aea 0x00005aea
.text : 9386 0x000024aa CODE 0x00005c00 0x00005c00
.bss : 123 0x0000007b UDATA 0x00001ef0 0x00001ef0
.data : 752 0x000002f0 UDATA 0x00001c00 0x00001c00
.stack : 160 0x000000a0 UDATA 0x00002360 0x00002360
AES256 : 2 0x00000002 DATA 0x0000ffcc 0x0000ffcc
RTC : 2 0x00000002 DATA 0x0000ffce 0x0000ffce
PORT4 : 2 0x00000002 DATA 0x0000ffd0 0x0000ffd0
PORT3 : 2 0x00000002 DATA 0x0000ffd2 0x0000ffd2
TIMER3_A1 : 2 0x00000002 DATA 0x0000ffd4 0x0000ffd4
TIMER3_A0 : 2 0x00000002 DATA 0x0000ffd6 0x0000ffd6
PORT2 : 2 0x00000002 DATA 0x0000ffd8 0x0000ffd8
TIMER2_A1 : 2 0x00000002 DATA 0x0000ffda 0x0000ffda
TIMER2_A0 : 2 0x00000002 DATA 0x0000ffdc 0x0000ffdc
PORT1 : 2 0x00000002 DATA 0x0000ffde 0x0000ffde
TIMER1_A1 : 2 0x00000002 DATA 0x0000ffe0 0x0000ffe0
TIMER1_A0 : 2 0x00000002 DATA 0x0000ffe2 0x0000ffe2
DMA : 2 0x00000002 DATA 0x0000ffe4 0x0000ffe4
USCI_A1 : 2 0x00000002 DATA 0x0000ffe6 0x0000ffe6
TIMER0_A1 : 2 0x00000002 DATA 0x0000ffe8 0x0000ffe8
TIMER0_A0 : 2 0x00000002 DATA 0x0000ffea 0x0000ffea
ADC12 : 2 0x00000002 DATA 0x0000ffec 0x0000ffec
USCI_B0 : 2 0x00000002 DATA 0x0000ffee 0x0000ffee
USCI_A0 : 2 0x00000002 DATA 0x0000fff0 0x0000fff0
WDT : 2 0x00000002 DATA 0x0000fff2 0x0000fff2
TIMER0_B1 : 2 0x00000002 DATA 0x0000fff4 0x0000fff4
TIMER0_B0 : 2 0x00000002 DATA 0x0000fff6 0x0000fff6
COMP_E : 2 0x00000002 DATA 0x0000fff8 0x0000fff8
UNMI : 2 0x00000002 DATA 0x0000fffa 0x0000fffa
SYSNMI : 2 0x00000002 DATA 0x0000fffc 0x0000fffc
.reset : 2 0x00000002 DATA 0x0000fffe 0x0000fffe
------------------------------------------------------------
Totals by section type
------------------------------------------------------------
Uninitialized Data : 1035 0x0000040b
Initialized Data : 5584 0x000015d0
Code : 9386 0x000024aa
2. After loading the program in the CCS debugger, and with the program halted at the entry to main the Verify Program operation passes:
MSP430: Program verification successful for /home/mr_halfword/workspace_v9/Cold_Chain_Demo_v1_00/Debug/Cold_Chain_Demo_v1_00.out
From the debug server load_and_verify.log in the attached zip file can see the following memory areas being read using GTI_READMEM_BLK during the verification:
| Start address | Length |
| 0x00004400 | 0x00001224 |
| 0x00005800 | 0x0000037A |
| 0x00005C00 | 0x000024AA |
| 0x0000FFCC | 0x00000034 |
Where the above covers the range of initialised sections in the out file.
3. Run the program which changes the values in the .TI.noinit section, pause the program and attempt to perform a Verify Program which fails with:
MSP430: File Loader: Verification failed: Values at address 0x04400 do not match Please verify target memory and memory map.
From the verify_fail.log in the attached zip file can only the following memory area being read using GTI_READMEM_BLK during the verification:
| Start address | Length |
| 0x00004400 | 0x00001224 |
Is it possible that the CCS Verify Program can be configured to check all memory sections rather than just stopping on the first error, reporting a pass/fail to individual sections in the program?
That would help debugging with programs with initialised sections which are expected to change once the program has started running.
