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.

TMS320F28027F: Encryption issue

Part Number: TMS320F28027F
Other Parts Discussed in Thread: C2000WARE

Hi team,

Here're few questions from the customer may need your help:

1) Encryption generally succeeds when the TMS320f28027F is encrypted with the CCS11.2 version. However, the following reminder appears when decrypting, "Device unlocked. To clear the programd password, please erase sector A of Flash memory. " While Node A has chosen to erase, is it necessary to be under wait in bootload to unlock when decryption? 

2) Why does some chips fail to work after encryption?

3) Adding the file _CSMpasswords.ASM, encrypting as a file, can the CCS on-chip flash password be emulated if the same password is used?

Could you help look into this case? Thanks.

Best Regards,

Cherry

  • Cherry,

              The correct term we want to use is “securing”, not “encryption”, since we are not encrypting the code but securing the memory from unauthorized access.

    While Node A has chosen to erase, is it necessary to be under wait in bootload to unlock when decryption? 

    No. The "Wait" bootmode is used only during power-up. It is useful to keep the device looping in boot-ROM and not access the flash, which is a secure resource. If the flash is accessed in a secure device, it would trigger the ECSL logic and break the debugger connection. To summarize, the "Wait" bootmode is not relevant during Erase/Program operation of the the Flash.

    2) Why does some chips fail to work after encryption?

    This should not happen. Securing the device should have no bearing on device operation, especially in standalone mode. There is something else that is wrong. The CSM module has nothing to do with this.

    3) Adding the file _CSMpasswords.ASM, encrypting as a file, can the CCS on-chip flash password be emulated if the same password is used?

    I presume what you are asking is whether passwords can be added using the CCS on-chip flash programmer the same way we add them to a project using _csmpasswords.asm. If so, the answer is “yes”.

  • Hi Hareesh,

    Thanks for your support and the answers do help a lot!

      The correct term we want to use is “securing”, not “encryption”, since we are not encrypting the code but securing the memory from unauthorized access.

    Thanks for your reminder.

    This should not happen. Securing the device should have no bearing on device operation, especially in standalone mode. There is something else that is wrong. The CSM module has nothing to do with this.

    There is still an issue where the securing program does not work. As the program does cannot work without the emulator DBUG, while the program works fine in the emulation state.

    The program may not run without an emulator since it is under Wait in Bootload mode or because the address of CodeStartBranch.ASM is affected. May I know is there any possible cause other than the above two possibilities?

    Thanks and regards,

    Cherry

  • There is still an issue where the securing program does not work. As the program does cannot work without the emulator DBUG, while the program works fine in the emulation state.

    OK, this is the case where code works fine with the JTAG debug probe connected but not without it. That is, project runs fine when run through CCS but not in standalone mode. This has been addressed on e2e numerous times. Please refer https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/757590.

    The program may not run without an emulator since it is under Wait in Bootload mode

    The "Wait" bootmode should not be used under normal circumstances. To boot from Flash in standalone mode, only GetMode should be used.

    or because the address of CodeStartBranch.ASM is affected.

    If you use the default linker command file that comes as part of C2000ware, everything will be placed at the correct address.

  • Hi Hareesh,

    While the case still persist, when securing the code, the behavior is as follows:

    When the f2802x_csmppasswords.ASM file is added, the program cannot run without modifying the password. However, if the password is modified, the emulator program will not run if it is re-flashed. 

    And here's a thread on e2echina forum, which had mentioned that "the user uses the RAM of a non-secure zone when encrypted, use it as the ram of a secure zone instead."

    However, the CMD file configuration is the same as mentioned in the text. Is it possible to be secured through the 28027 routine?

    Thanks and regards,

    Cherry

  • Cherry,

              I am sorry I don’t understand what exactly the issue is. As mentioned before, securing or not securing a device does not impact the execution of the application. Can you provide a clear summary of the issue?

  • Hi Hareesh,

    Please let me specify more on the case:

    The customer added the f2802x_csmppasswords.ASM file to the project of the program in use,  according to the customer's understanding, the essence of this file is to write the appropriate password to CSM, that is, to the corresponding address(CSM_PWL_P0 : origin = 0x3F7FF8, length = 0x000008 ). However, during actual debugging, when the file is added and 0xffff is written to all addresses, the program starts normally without the emulator. However, when changing this address to the password written by the customer, the program cannot be started without an emulator. That is, after changing the address from 0x3F7FF8 to 0x3F7FFF, the program cannot start. However, according to the 28027 guide, the address of the CSM is 8 of these bits.

    Addresses 0x3F7FF8 through 0x3F7FFF should not be accessed when getmode() is started directly when the chip is powered on. If not, why does the program fail to start at power up?

    Please let me know if anything unclear.

    Thanks and Regards,

    Cherry

  • Cherry,

         I will respond early next week. 

  • Cherry,

              As clarified earlier, security does not impact code execution. I also pointed customer to an e2e post that discusses why code may not run without emulator. There is something the customer is doing which we are unaware of. This is a very old module (almost 20 years old) and is fairly straightforward to understand, compared to DCSM. Please have customer try a simple GPIO toggling code with security, as opposed to their project. They can also examine their .map file for correct placement of DSP2803x_CodeStartBranch.asm and the passwords. Sorry I am unable to help.