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.

TMS320F28388D: DCSM security tool example - data verification error during load

Part Number: TMS320F28388D

Hi,

I have been exploring the DCSM security with the dcsm_ex1_secure_memory_partition and dcsm_security_tool examples. In a first I succeeded to advance the LINKPOINTER values to iterate to a new zone and flip more bits on the Z1OTP_CSMPSWD.
As next step to test the DCSM feature, I attempted to advance the link pointer once more by updating the current linkpointer value in the with the dcsm_security_tool.syscfg mechanism (00003FFE to 00003FFC) . The dcsm,asm file generated seem to be quite alright to achieve that goal. Yet when starting to debug so that the program is loaded on CPU1 I encounter a data verification error. A related post in the forum on the data verification problem seems to suggest that the memory is inaccessible.

Would you be able to point me to things to verify when this error info is presented on the console:


Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: GEL Output:
... DCSM Initialization Start ...
C28xx_CPU1: GEL Output:
DCSM bitpos 1
C28xx_CPU1: GEL Output:
... DCSM Initialization Done ...
C28xx_CPU1: GEL Output:
CPU2 is out of reset and configured to wait boot.
(If you connected previously, may have to resume CPU2 to reach wait boot loop.)
C28xx_CPU1: GEL Output:
CM is out of reset and configured to wait boot.
(If you connected previously, may have to resume CM to reach wait boot loop.)
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. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU1: Only CPU1 on-chip Flash Plugin can configure clock for CPU1, CPU2 and CM Flash operations. Plugin automatically configures PLL when CPU1 Flash operations are invoked. However, if users want to do only CPU2 or CM Flash operations without doing a prior CPU1 operation in the current session, they should click on 'Configure Clock' button in CPU1's on-chip Flash Plugin before invoking CPU2 and CM Flash operations. When this button is used, Flash Plugin will configure the clock for CPU1/CPU2 at 190MHz and CM at 95MHz using INTOSC2 as the clock source. Plugin will leave PLL config like this and user application should configure the PLL as required by application.
C28xx_CPU1: GEL Output:
... DCSM Initialization Start ...
C28xx_CPU1: GEL Output:
DCSM bitpos 1
C28xx_CPU1: GEL Output:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Please advise on other files that might be useful to attach to this post.

Best regards,

Frank

  • Hi Frank,

    Could you change your project's active configuration from Ram to Flash? It looks like the .out file you are using is being generated in the CPU1_RAM folder.

    Let me know if this resolves your issue.

    Thank you,

    Luke

  • Hi Luke,

    thanks for your assistance!
    It seems that a change of the active configuration to FLASH did not resolve the problem per se. I hope you bear with me a little further....

    After the change from RAM to FLASH I receive now an 'Unknown error'. Here would be the copy+paste of the console:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    C28xx_CPU1: GEL Output:
    Memory Map Initialization Complete
    C28xx_CPU1: GEL Output:
    ... DCSM Initialization Start ...
    C28xx_CPU1: GEL Output:
    DCSM bitpos 1
    C28xx_CPU1: GEL Output:
    ... DCSM Initialization Done ...
    C28xx_CPU1: GEL Output:
    CPU2 is out of reset and configured to wait boot.
    (If you connected previously, may have to resume CPU2 to reach wait boot loop.)
    C28xx_CPU1: GEL Output:
    CM is out of reset and configured to wait boot.
    (If you connected previously, may have to resume CM to reach wait boot loop.)
    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. User code execution from SR could commence after both flash banks are programmed.
    C28xx_CPU1: Only CPU1 on-chip Flash Plugin can configure clock for CPU1, CPU2 and CM Flash operations. Plugin automatically configures PLL when CPU1 Flash operations are invoked. However, if users want to do only CPU2 or CM Flash operations without doing a prior CPU1 operation in the current session, they should click on 'Configure Clock' button in CPU1's on-chip Flash Plugin before invoking CPU2 and CM Flash operations. When this button is used, Flash Plugin will configure the clock for CPU1/CPU2 at 190MHz and CM at 95MHz using INTOSC2 as the clock source. Plugin will leave PLL config like this and user application should configure the PLL as required by application.
    C28xx_CPU1: GEL Output:
    ... DCSM Initialization Start ...
    C28xx_CPU1: GEL Output:
    DCSM bitpos 1
    C28xx_CPU1: GEL Output:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Another observation:
    The entire flash is part of zone1 security. Once I place an invalid password into CSMPSWD section under 'Flash Settings' of the project's launch configuration properties I observe the error message:

    Fullscreen
    1
    C28xx_CPU1: Warning: Failed unlocking device (zone 1) after reset.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Thus I assume that the unlock of zone1 flash is done successfully by the flash tool once this error message is absent, therefore ruling this out as a problem source?!?

    Best regards,

    Frank

  • Hi Frank,

    This error message should point us to the cause of this issue:

    C28xx_CPU1: Error during Flash Programming. Address 0x00078000, Data 0x0000E000, FMSTAT 0x00000030

    The link pointer is at address 0x78000. Either you are attempting to program a link pointer that contains 1s in bit locations that are currently programmed as 0s,

    OR

    The device is still secure when you attempt to program the flash and DCSM settings. To check this, you can look up address 0x78000 in the memory browser. If you see all 0s (with the exception of the CSM passwords), then the device is secure. You must unlock the device via the On-Chip Flash tool in CCS (located in the Tools tab after you have connected to the device) before attempting to program the flash or USER OTP.

    Also, there is a check-box in the On-Chip Flash tool labeled something like "Reset device before programming". If you have programmed CSM passwords or modified the linkpointer, you must un-check this box, since the device will become locked upon reset.

    Let me know if this resolves your issue.

    Thank you,

    Luke

  • Hi Luke,

    The issue is resolved!

    FYI I believe that it was the second option - the password setting on the on-chip flash tool and the 'Reset the target on a program load or restart'.
    I didn't quite find the  "Reset device before programming" in my version of the CCS (11.1.0.00011). There is a check-box called 'Reset on Connect' on the launch configuration properties under  Target tab -> Flash Settings. As that check-box was already unchecked I located anything related to 'reset' and unchecked it. 

    Bottom line, I could change the LINKPOINTER value as desired using the On-Chip Flash tool using the 'Progam' button once I start a debug session.

    Many thanks indeed for pointing to the On-Chip flash tool!

    Frank