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.

TMS320F28375D: Code Secure Module - Failing to update FLSEM register

Part Number: TMS320F28375D
Other Parts Discussed in Thread: CONTROLSUITE, UNIFLASH

My problem is basically the same with this post, which is secure bootloader that can update the code in the secure flash memory. When the bootloader trys to update the code, it seems that CPU resets and jumps to the pointed application address from bootloader.

I followed the solution that is posted in the link above (the code below), but I could not update FLSEM register value to make semaphore enabling for zone 1.

DcsmCommonRegs.FLSEM.all = 0xA501; // 0xA502 for Zone2

I also tried to update the FLSEM register while I was debugging with CCS manually, but it also failed to update the FLSEM register value.

In summary, I have two questions:

  1. To update FLSEM register, is there any other step to follow before updating the register?
  2. Resetting CPU is expected result when semaphore is not enabled, and it will fix the issue by enabling semaphore?

Thanks,

Justin

  • Hi Justin,

    To update FLSEM register, is there any other step to follow before updating the register?

    You need to make sure that this piece of code is running from Zone1 only else it'll not be able to update the semaphore value. Also this register can not be updated via CCS.

    Resetting CPU is expected result when semaphore is not enabled, and it will fix the issue by enabling semaphore?

    If you have watchdog enable then yes, device could get reset. There could be other reason also for reset.  Please correct the step 1 and see if that helps.

    Regards,

    Vivek Singh

  • Hi Vivek,

    I got mixed result, but most likely, I have a different issue.

    I copied DCSM_Z1_ZoneSelectBlock.asm file from the controlSUITE example.  I also modified 2837xD_dcsm_lnk_cpu1.cmd file and removed "type = DSECT".

    SECTIONS
    {
       dcsm_otp_z1_linkpointer 	: > DCSM_OTP_Z1_LINKPOINTER	PAGE = 0
       dcsm_otp_z1_pswdlock		: > DCSM_OTP_Z1_PSWDLOCK		PAGE = 0
       dcsm_otp_z1_crclock		: > DCSM_OTP_Z1_CRCLOCK		PAGE = 0
       dcsm_otp_z1_bootctrl		: > DCSM_OTP_Z1_BOOTCTRL		PAGE = 0
       dcsm_zsel_z1				: > DCSM_ZSEL_Z1_P0				PAGE = 0
    
       dcsm_otp_z2_linkpointer	: > DCSM_OTP_Z2_LINKPOINTER	PAGE = 0, type = DSECT
       dcsm_otp_z2_pswdlock		: > DCSM_OTP_Z2_PSWDLOCK		PAGE = 0, type = DSECT
       dcsm_otp_z2_crclock		: > DCSM_OTP_Z2_CRCLOCK		PAGE = 0, type = DSECT
       dcsm_otp_z2_bootctrl		: > DCSM_OTP_Z2_BOOTCTRL		PAGE = 0, type = DSECT
       dcsm_zsel_z2				: > DCSM_ZSEL_Z2_P0				PAGE = 0, type = DSECT
    }

    The problem now I am seeing is that, when I uncomment  the following lines for configuring secure memory and password, bootloader failed to jump to the application.

          .sect "dcsm_zsel_z1"
          .long 0xFFFFFFFF      ;Z1-EXEONLYRAM
          .long 0xFFFFFFFF      ;Z1-EXEONLYSECT
          .long 0xFFFF5555      ;Z1-GRABRAM
          .long 0xF5555555      ;Z1-GRABSECT
    
          .long 0x12345678      ;Z1-CSMPSWD0 (LSW of 128-bit password)
          .long 0x90ABCDEF      ;Z1-CSMPSWD1
          .long 0x12345678      ;Z1-CSMPSWD2
          .long 0x90ABCDEF      ;Z1-CSMPSWD3 (MSW of 128-bit password)

    If I comment out the lines above, bootloader jumps to the application.

    Thanks,

    Justin

  • Hi Justin,

    Please note that secure bootloader you can only update the code in secure flash without unlocking the zone. To update the security settings in USER OTP, you need to unlock the device using correct password.

    Regards,

    Vivek Singh
  • Here is update.

    After searching more cases for CSM, I could get some useful information.

    My firmware image is composed of three files. Bootloader, application image 0, application image 1. Application image 0 and image 1 are identical. After power up, bootloader will be run and jump to the one of application image (if image 0 is not valid).

    Issue:

    • If I download modified bootloader (jump disabled. Turn on a LED for testing) itself, code/JTAG is successfully locked. I had to use Wait Boot Mode to unlock it.
    If I download the whole firmware image (BL + Image0 + Image1), it failed to run bootloader - no SW running at all from the beginning
    • I double checked only Dx and LSx RAMs are used for bootloader, image0 and image1

    CSM is enabled only in the bootloader project, so I tried to apply the same CSM configurations to Image0 and Image1. What I am observing is that CSM-applied and non-CSM-applied generated binary file size are different. CSM-applied built image is twice bigger than non-CSM-applied version. I compared map file, but the only difference is CSM section is added, which does not explain the twice size difference. Because of that, which exceeds defined flash memory size, I could not try this.

  • Hi Justin,

    In my case, I found that Mx was using by .stack section, so I changed it to use LSx RAM.

    You should be able to use Mx RAMs for .stack. That should not be issue. Infact using secure RAM for .stack may create issue if you have code running from non-secure RAM also.

    I am not sure about the issue of image file size getting two times if CSM enabled. Please check the map file.

    I asked in last post if you are also trying to program the value in USER OTP. It will be good if you can explain a bit more about what are you trying to do here and how (each step).

    Regards,

    Vivek Singh

  • Update:

    First of all, since I only user zone1 and zone select contents, my linker command file for CSM is like the following.

    MEMORY
    {
    PAGE 0 :  /* Program Memory */
    
       /* Z1 OTP.  LinkPointers */
       DCSM_OTP_Z1_LINKPOINTER   : origin = 0x78000, length = 0x00000C
       /* Z1 OTP.  PSWDLOCK/RESERVED */
       DCSM_OTP_Z1_PSWDLOCK	    : origin = 0x78010, length = 0x000004
       /* Z1 OTP.  CRCLOCK/RESERVED */
       DCSM_OTP_Z1_CRCLOCK	    : origin = 0x78014, length = 0x000004
       /* Z1 OTP.  RESERVED/BOOTCTRL */
       DCSM_OTP_Z1_BOOTCTRL	    : origin = 0x7801C, length = 0x000004
    
       /* DCSM Z1 Zone Select Contents (!!Movable!!) */
       /* Z1 OTP.  Z1 password locations / Flash and RAM partitioning */
       DCSM_ZSEL_Z1_P0	        : origin = 0x78020, length = 0x000010
    
       /* Z2 OTP.  LinkPointers */
       DCSM_OTP_Z2_LINKPOINTER	: origin = 0x78200, length = 0x00000C
       /* Z2 OTP.  GPREG1/GPREG2 */
       DCSM_OTP_Z2_GPREG	        : origin = 0x7820C, length = 0x000004
       /* Z2 OTP.  PSWDLOCK/RESERVED */
       DCSM_OTP_Z2_PSWDLOCK	    : origin = 0x78210, length = 0x000004
       /* Z2 OTP.  CRCLOCK/RESERVED */
       DCSM_OTP_Z2_CRCLOCK	    : origin = 0x78214, length = 0x000004
       /* Z2 OTP.  GPREG3/BOOTCTRL */
       DCSM_OTP_Z2_BOOTCTRL	    : origin = 0x7821C, length = 0x000004
    
       /* DCSM Z1 Zone Select Contents (!!Movable!!) */
       /* Z2 OTP.  Z2 password locations / Flash and RAM partitioning  */
       DCSM_ZSEL_Z2_P0	        : origin = 0x78220, length = 0x000010
    
    }
    
    SECTIONS
    {
       dcsm_otp_z1_linkpointer 	: > DCSM_OTP_Z1_LINKPOINTER		PAGE = 0, type = DSECT
       dcsm_otp_z1_pswdlock		: > DCSM_OTP_Z1_PSWDLOCK		PAGE = 0, type = DSECT
       dcsm_otp_z1_crclock		: > DCSM_OTP_Z1_CRCLOCK			PAGE = 0, type = DSECT
       dcsm_otp_z1_bootctrl		: > DCSM_OTP_Z1_BOOTCTRL		PAGE = 0, type = DSECT
       dcsm_zsel_z1			: > DCSM_ZSEL_Z1_P0			PAGE = 0
    }

    Working Part:

    • Loading CSM enabled bootloader .out file works.
      • Bootloader start address is 0x80000
      • In the debugging mode, padded value for the hole between DCSMZSEL_Z1_P0 (0x78030) and 0x80000 is 0xFF, while .bin file holes are filled with 0x00.
        • To generate .bin file, the following post-build step is added:
          • "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000.exe" "${CG_TOOL_ROOT}/bin/hex2000.exe" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

    • Assumption is that leaving 00s between 0x78030 and 0x80000 will lock zone2 password section, which will lock everything. Therefore, I tried the following two methods to fix the issue.

    Method 1 Problem:

    • Based on that result, I compared with the .out file and .bin file. Hole was padded with 0x00, so I added --fill=0xFFFF option to hex2000.exe file execution.
      • I tried to flash this .bin file using Uniflash. I entered 0x78020for the starting address to load the binary file and got the following two different error messages:
        • [13:24:13] Begin Launching session operation.
          [13:24:18] Operation Launching session returned. 
          [13:24:18] Loaded target configuration from: C:\Users\justin\Documents\XDS510_Delfino.ccxml
          [13:24:46] Begin Writing flash memory operation.
          [13:24:48] C28xx_CPU1: GEL Output: 
          Memory Map Initialization Complete
          
          [13:24:48] C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code.  Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
          
          [13:24:49] Loading program at 0x7820: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin
          [13:24:50] WARNING >> C28xx_CPU1: Loader: One or more sections of your program falls into a memory region that is not writable.  These regions will not actually be written to the target.  Check your linker configuration and/or memory map.
          
          [13:24:52] ERROR >> C28xx_CPU1: File Loader: Verification failed: Values at address 0x000000000000B818 do not match Please verify target memory and memory map.
          
          [13:24:52] ERROR >> C28xx_CPU1: GEL: File: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin: a data verification error occurred, file load failed.
          
          [13:24:52] File: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin: a data verification error occurred, file load failed.
          [13:24:52] Operation Writing flash memory returned. 
          

        • [14:42:17] Begin Launching session operation.
          [14:42:21] Operation Launching session returned. 
          [14:42:21] Loaded target configuration from: C:\Users\justin\Documents\XDS510_Delfino.ccxml
          [14:42:33] Begin Writing flash memory operation.
          [14:42:35] C28xx_CPU1: GEL Output: 
          Memory Map Initialization Complete
          
          [14:42:35] C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code.  Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
          
          [14:42:35] Loading program at 0x78020: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin
          [14:42:35] C28xx_CPU1: Writing Flash @ Address 0x00078020 of Length 0x00003ff8 (page 0)
          
          [14:42:37] ERROR >> C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code). Operation cancelled.
          
          [14:42:37] ERROR >> C28xx_CPU1: File Loader: Memory write failed: Unknown error
          
          [14:42:37] ERROR >> C28xx_CPU1: GEL: File: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin: Load failed.
          
          [14:42:37] File: C:\Empower\FlexGate_Gen_Two\Code\flexgate_engineering\bootloader_ccs\Enable_DCSM\ems_bootloader_cpu01.bin: Load failed.
          [14:42:38] Operation Writing flash memory returned. 

    Method 2 Problem:

    • Based on the result of Method 1, I revert the filling hole with 0xFFFF to default for hex2000.exe which will fill the hole with 0x00. Then, I only filled Z1 and Z2 with 0xFF except for the DCSMZSEL_Z1_P0 section.
      • I tried to flash this .bin file using Uniflash. I entered 0x78020 for the starting address to load the binary file and got the following error message:
        • [13:49:29] Begin Launching session operation.
          [13:49:37] Operation Launching session returned. 
          [13:49:37] Loaded target configuration from: C:\Users\justin\Documents\XDS510_Delfino.ccxml
          [13:49:44] Begin Unlock operation.
          [13:49:46] C28xx_CPU1: GEL Output: 
          Memory Map Initialization Complete
          
          [13:49:46] ERROR >> C28xx_CPU1: Trouble Writing Register XAR0: Error 0x00001004/-1041 Error during: Register, Target,  Device driver: Problem with the Emulation Controller. It is recommended to RESET EMULATOR.  This will disconnect each  target from the emulator.  The targets should then be power cycled or hard reset followed by an emureset and reconnect to each target.  
          
          [13:49:48] ERROR >> C28xx_CPU1: GEL: Error while executing OnReset(0): Target failed to write register XAR0
          	at XAR0=*((unsigned long *) 0x78018) [f28375d_cpu1.gel:401]
          	at SetupDCSM() [f28375d_cpu1.gel:32]
          	at OnReset(0)
          
          [13:49:48] ERROR >> C28xx_CPU1: Trouble Writing Memory Block at 0x5fb00 on Page 0 of Length 0x2: Error 0x00001006/-1041 Error during: Memory, Register, Target,  Device driver: Problem with the Emulation Controller. It is recommended to RESET EMULATOR.  This will disconnect each  target from the emulator.  The targets should then be power cycled or hard reset followed by an emureset and reconnect to each target.  
          
          [13:49:49] ERROR >> C28xx_CPU1: Error occurred during flash operation: Target failed to write 0x5FB00@Program
          
          [13:49:49] ERROR >> C28xx_CPU1: Trouble Writing Memory Block at 0x5f800 on Page 1 of Length 0x2: Error 0x00001002/-1156 Error during: Memory, Target,  Lost processor clock. Device may be operating in a low-power mode.  Do you want to bring it out of this mode?  
          
          [13:49:51] ERROR >> C28xx_CPU1: Error occurred during flash operation: Could not write 0x0005F800@Data: target is not connected
          
          [13:49:51] ERROR >> C28xx_CPU1: Error occurred during flash operation: Could not read 0x70268@Program: target is not connected
          
          [13:49:51] ERROR >> C28xx_CPU1: Error occurred during flash operation: Could not read 0x700B0@Program: target is not connected
          
          [13:49:51] ERROR >> C28xx_CPU1: Error occurred during flash operation: Could not write 0x5FB00@Program: target is not connected
          
          [13:49:51] Operation Unlock returned. 

        • After this message, CPU was some how locked, so I could not program this CPU again.

  • Hi Justin,

    •Assumption is that leaving 00s between 0x78030 and 0x80000 will lock zone2 password section, which will lock everything. Therefore, I tried the following two methods to fix the issue.


    Your assumption was correct. We should never program the security settings with all 0x0 else device will be permanently locked and that is what happened in the method 2 you tried.

    I am looping in our uniflash expert to look into the error you are getting.

    Regards,

    Vivek Singh
  • Using hex file instead of bin file was a workaround to avoid writing 0s or unnecessary memory section programming. It is because hex file specifies memory address to write.