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: Self-programming via EMIF on a C2000 with DCSM enabled

Genius 5785 points
Part Number: TMS320F28375D
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Hi experts,

My customer created a custom board using the F28375D.
When they performed self-programming via EMIF on a C2000 with DCSM enabled, the software rewrite failed.
FlashAPI provided by TI is used for self-programming, and self-programming can be performed without any problems unless DCSM is enabled.

Q:Are there any settings or precautions required when performing self-flash using FlashAPI with DCSM enabled?

[DCSM settings]

  • Z1-LinkPointer1~3 remain at default 0xFFFFFFFF
  • Set all Z1-CSMPSWD0~3 to 0xFFFFFFF1
  • Set Z1-GRAMBSECT to 0x0AAAAAAA
  • Set Z1-GRABRAM to 0x10005555
  • *Other than the above, leave as default

They tried setting the following registers using the sample source that supports self-programming using DCSM as a reference, but it did not improve the situation.
c2000\C2000Ware_5_01_00_00\device_support\f2837xd\examples\cpu1\flash_programming_dcsm\cpu01/flash_programming_dcsm_cpu01.c

  • DcsmCommonRegs.FLSEM.all = 0xA501;
  • Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

The DSP during self-programming is started from Get mode.

Best regards,
O.H

  • Hi O.H,

    When the GRABRAM/GRABSECT bits corresponding with a memory region are programmed to "10" and the zone is locked, that memory region will be inaccessible:

    Thank you,

    Luke

  • Hi Luke,

    Thank you for your reply.

    Could you tell me how to solve it?
    For example, can we solve the problem by referring to the following chapter of TRM and incorporating the release code?
    ・3.13.3.2 CSM Password Match Flow
    ・3.13.3.3 Unsecuring Considerations for Zones With and Without Code Security
    ・3.13.3.3.1 C Code Example to Unsecure C28x Zone1

    Please let me know if there is another method.

    Best regards,
    O.H

  • Hi O.H,

    You can resolve this issue by updating the LINKPOINTER and reprogramming the GRABSECT/GRABRAM fields to the correct values.

    The following video series explains the LINKPOINTER concept along with an overview of DCSM:

    https://www.ti.com/video/series/C2000-dual-code-security-module.html

    Thank you,

    Luke

  • Hi Luke,

    Does that mean that the following methods are the only options?
    Update GRABSECT/GRABRAM by updating LINKPOINTERT to unlock DCSM → Update firmware via EMIF → Update GRABSECT/GRABRAM to lock DCSM

    Best regards,
    O.H

  • Hi O.H.

    Is the firmware you're updating located in secure or unsecure memory? If located in secure memory, you will still need to unlock the DCSM before programming via EMIF. Otherwise, designating all locations that you wish to program as unsecure should resolve the issue.

    Thank you,

    Luke

  • Hi Luke,

    Thank you for your reply.

    Below are the customer's comments.
    ==========================

    A self-programming function is placed in RAM. The entire RAM and FLASH area is set as a secure area.

    For reference, here are the self-programming steps.
    The checksum values ​​do not match at step 7 below.

    1. Power on and start the device (start with Getmode). After initialization is complete, enter the normal routine.
      At this time, a self-programming function is also placed in RAM.
    2. A command to execute self-programming is sent via EMIF.
    3. Branch to self-programming processing
    4. Set FLSEM.all to 0xA501. Set Flash0EccRegs.ECC_ENABLE.bit.ENABLE to 0x0.
    5. Delete a specific Flash sector area
    6. Read the data via EMIF and perform the rewrite.
    7. Turn off the power, set the DSP to WaitBoot mode, and perform a checksum with UniFlash.

    I will verify the updating the LINKPOINTER, but please allow me to confirm this further.

    Q2: When updating LINKPOINTER, is it possible to set the same LINKPOINTER address to non-secure, perform self-programming, and then set it to secure?
    For example:Change Z1-LINKPOINTER1 to Z1-LINKPOINTER2 → perform self-programming → write to ZoneSelectBlock2
    If there is any reference information on setting secure(writing to ZoneSelectBlock) with C code without using Uniflash or CCS, please let me know.

    Q3: Since only 29 bits of LINKPOINTER are valid, does it mean that a maximum of 29 secure settings can be made on one device?

    Best regards,
    O.H

  • Hi O.H,

    Is the customer using the safe copy code function?

    Thank you,

    Luke

  • Hi Luke,

    The current setup does not use EXEONLY FLASH/RAM.

    Does this mean that "safe copy code" is required?
    If yes, could you tell me the reason?

    Best regards,
    O.H

  • Hi O.H,

    If the function that is doing the copying and writing of memory to secure FLASH is stored in non-secure memory then that could be the cause of the issue. What code is copying your code to flash?

    Thank you,

    Luke