TMS320F280041: issue with HAL_clearDataRAM

Tool/software:

Hello TI Team,

I'm using the Motor Control SDK Universal Project and Lab (Universal Motor Control Project and Lab User’s Guide (Rev. A)) and have a question regarding the linker symbols created (e.g, loadStart_user_data & loadSize_user_data ). When going through document TMS320C28x Assembly Language Tools v21.6.0.LTS User's Guide (Rev. W), there is the following information stated: 

• 8.6 Linker Symbols - 8.6.1 Using Linker Symbols in C/C++ Applications
• Linker symbols that represent a data address: In C code, declare the variable as an extern variable. Then, refer to the value of the linker symbol using the & operator. Because the variable is at a valid data address, we know that a data pointer can represent the value.

In the Motor Control SDK Universal Project and Lab, there is an initialization function "void boardInit()", in this function there are several function calls similar to this one:    

• HAL_clearDataRAM((void *)loadStart_user_data, (uint16_t)loadSize_user_data);

I believe there is a problem with this, since the value of loadStart_user_data which is passed onto the function is 0, due to the lack of the & operator usage. A fix I'm currently applying is the following:

    uint32_t sectionSize;
    sectionSize = (uint32_t)&loadSize_user_data;
    HAL_clearDataRAM((void *)&loadStart_user_data, (uint16_t)sectionSize);

This fix was especially necessary since when configuring the OTP to perform the emulation-only of the DCSM config.

Before applying the proposed fix onto HAL_clearDataRAM, when I connected the JTAG/emulator, load/run code. Reset via CCS (Scripts > Realtime Emulation Control > Run_Realtime_with_Reset; as in .c comments). I would get the following error:

• ERROR MESSAGE: Texas Instruments XDS110 USB Debug Probe/C28xx_CPU1 Trouble Reading Register PC: (Error -1142 @ 0x0) Device blocked debug access because it is currently executing non-debuggable code. Choose 'Rude Retry' to disable polite mode and force the operation. (Emulation package 20.2.0.3536).

Before the fix, I believe since the loadStart_user_data was lacking the & operator, the valeu 0 was being passed onto the function. Could you explain why the new DCSM code would would result in the ERROR MESSAGE before the HAL_clearDataRAM fix? Also, do you agree with the fix ? After the fix, the address values passed onto the function were no longer 0 as described in the following post: TMS320F2800132: issue with HAL_clearDataRAM or LOAD_START in linker cmd file - C2000 microcontrollers forum - C2000︎ microcontrollers - TI E2E support forums.

If necessary, I can share more information such as the linker file or the resulting .map.

Moreover, when activating the DCSM module (no longer emulation only) to boot from Flash Bank 0, Sector 0:

This generates the following assembly code: 

     .sect "dcsm_otp_z1_pswdlock"
      .retain
      .long 0xFB7FFFFF
      .long 0x7FFFFFFF     ;Reserved
      
     .sect "dcsm_otp_z1_crclock"
      .retain
      .long 0x4BFFFFFF
      .long 0x3FFFFFFF     ;Reserved
   
     .sect "dcsm_otp_z1_jtaglock"
      .retain
      .long 0x9FFFFFFF
      .long 0x0FFFFFFF     ;Reserved
     .sect "dcsm_otp_z1_gpreg"
      .retain
      .long 0x5AFFFFFF     ;Z1OTP_BOOTPIN_CONFIG
      .long 0x5AFFFFfF     ;Z1OTP_GPREG2
     .sect "dcsm_otp_z1_bootctrl"
      .retain
      .long 0xFFFFFF03     ;Z1OTP_BOOTDEF_LOW
      .long 0xFFFFFFFF     ;Z1OTP_BOOTDEF_HIGH

What concerns must one have regarding RAM sectors? Especially regarding the HAL_clearDataRAM instructions, since before my suggested fix, during the emulation, the boards would freeze. I want to prevent sending wrong OTP code. 

Thanks,

Martin