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/NFC-DATALOGGER-EVM: Can CCS 9.1 Verifiy Program be configured to check all sections rather than stopping on the first error?

Other Parts Discussed in Thread: MSP-FET, MSP430FR5969

Tool/software: Code Composer Studio

Was using CCS 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- -x ~/workspace_v9/Cold_Chain_Demo_v1_00/Debug/Cold_Chain_Demo_v1_00.out | ~/ti/ti-processor-sdk-rtos-am335x-evm- 
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.

  • Chester,

    There is no way to configure the verify to report all errors today.

    One thought we had was to see if we marked the section as write-only if the verification would skip it.  Unfortunately I tried that and it just reports back an error saying the memory map prevents the reading of that address.

    Maybe in verification we need to somehow know to skip or just warn when there is a mismatch with something in .TI.noinit.  That could even be smart where we verify this section on load but not on a manual verify action.

    I need to look into .TI.noinit some more.



  • JohnS said:
    Maybe in verification we need to somehow know to skip or just warn when there is a mismatch with something in .TI.noinit.  That could even be smart where we verify this section on load but not on a manual verify action.

    I like the idea of different behaviour on load .vs. manual verify action.

    On Cortex-A projects which use the "RAM auto initialization model" I have seen a similar issue with the .data section in that verifies successfully upon load, but a manual verify fails on the .data section after the program has been running.

    Rather than add special logic for .TI.noinit perhaps:

    a. On load a verification failure on any initialised section is an error.

    b. On a manual verification:
    - Any verification failure on an initialised section without write permission is an error; since the running program is not expected to change the section contents.
    - Any verification failure on an initialised section with write permission is a warning, and verification continues with the next section.

  • For b) we would need to make sure it is easy to cancel the operation as well.


  • Chester,

    We are tracking this with CCBT-2520