CCS/RM57L843: Can not get the value of global variable in continuous refresh mode - CCS 7.1 Debug

Hello Hung Dang,

The post that you point to has the work around also posted in it with the verified answer. The original poster of the question also indicated success when implementing the work around.

With that said, the behavior of the RM57 might be a bit different in that it employs Cache memory. To make globals more consistent and available throughout, you may wish to configure the memory as write through memory. Also, it might be helpful if you declare your variable with the global or static keyword to assure they are preserved across all contexts within your application.

I try to debug my code which run on the LAUNCHXL2-RM57Lkit. But I can not get the value of  "temp" global variable in CCS 7.1 debug window.

With CCS 7.2.0.00012 found that the CCS debugger can read from the device while a program is running when using a LAUNCHXL2-570LC43. E.g. while a program is running the Expression view could continuously refresh the value of the GioB_DOut GPIO peripheral register which was being updated by the running program.

However, when the running program had enabled the cache with write-back on the SRAM memory region the value of a global variable updated by the running program was not displayed correctly while the program was running, in that the expression view showed the value as zero while the program was running. When the program was suspended the global variable was displayed correctly.

This is because when the program is running the DAP is used to perform reads, and when the program is suspended the CPU is used to perform reads. Reads from the CPU can obtain data from the cache, the reads from the DAP can only access memory. Therefore, if the CPU is updating variables in the cache the DAP won't be able to see the updated value while the program is running.

Possible options are:

1) After updating variables which need to be observed when the program is running perform a cache clean operation to write the updated value to memory.

2) Place variables which need to be observed / changed when the program is running in cache inhibited memory.

3) Change the MPU settings for the SRAM memory region to configure the cache for write-through rather than write-back.

4) Disable the cache.

Option 1) will have the least performance impact on the running program. As an example had the following global variable in a program running on a LAUNCHXL2-570LC43 where HALCoGen had been configured to enable the cache:

unsigned int num_interrupts;

The initial program simply incremented the num_interrupts variable in an interrupt routine:

void rtiNotification(rtiBASE_t *rtiREG, uint32 notification)
{
/*  enter user code between the USER CODE BEGIN and USER CODE END. */
    gioToggleBit (gioPORTB, 6);
    gioToggleBit (gioPORTB, 7);
    num_interrupts++;
}

With the above code while the program was running the CCS debugger expression view for the CortexR5 reported the value of num_interrupts as zero since was only being updated in the CPU cache.

The interrupt routine was then modified to perform a cache clean to write back the num_interrupts variable to memory after each update:

void rtiNotification(rtiBASE_t *rtiREG, uint32 notification)
{
/*  enter user code between the USER CODE BEGIN and USER CODE END. */
    gioToggleBit (gioPORTB, 6);
    gioToggleBit (gioPORTB, 7);
    num_interrupts++;

    /* Perform a "Clean data cache line by MVA to PoC" operation on the cache line containing the num_interrupts
     * variable to write-back the modified cache line to memory. This allows changes to the num_interrupts variable
     * to be monitored by the DAP while the program continues to be run, since the DAP only accesses memory
     * and there is no hardware cache coherency.
     *
     * Since num_interrupts is a 32-bit integer it will not occupy more than one 32 bytes Cortex-R5 cache line,
     * hence one operation is sufficient.
     */
    __MCR (15, 0, (unsigned int) &num_interrupts, 7, 10, 1);
}

With the above modification while the program was running CCS debugger expression view for the CortexR5 then showed updates to the num_interrupts variable.

As of HALCoGen 04.06.00 there doesn't appear to be any functions to perform cache management operations, so made use of the TI ARM __MCR compiler intrinsic to access the co-processor register to perform the ARM Cortex-R5 cache operation

The example CCS project is attached 

1738.TMS570LC4357_rtiblinky.zip

Edit: Clarify that tested the cache set to write-back for the SRAM memory region.