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.

TMS320F28384D: One DCSM question.

Part Number: TMS320F28384D

Hi champs,

There are two zones for DCSM and this is for the case, for example two companies work together for one project in single DSP device.

My question is that if my customer owns entire project and he enables Zone1 password, is it necessary to secure the flash sectors and RAM to Zone1?

I think it is okay not to secure flash and RAM, just enable Zone1 password to secure device. Is there any concern of this use case please?

Regards,

Luke

  • Hi Luke,

    This use case should be fine. Changing the password from the default value will only secure the security settings for zone 1, so the customer would need to unlock their device before each attempt to view or program their security settings.

  • I use F280025C LP to evaluate this DCSM function and get below questions,

    • I set password and do password lock, I can reprogram the device with correct passwords even DSP set to flash boot, not SCI boot, is it reasonable?
    • I can use Target Configuration method and connect to DSP device without passwords, means that I don't need to unlock device and can see all unsecure flash sectors and RAM, is it reasonable?

    I assume that CCS cannot connect to DSP via JTAG without correct passwords, but seems I am wrong. Is this normal situation or is there any I missed please?

    Regards,

    Luke

  • Hi Luke,

    Password lock should only be used once the user has finalized their security settings. This is a permanent setting that makes passwords unreadable when the device is secure, so the customer would risk permanently locking their device if they forget or incorrectly program their passwords.

    I am not sure I understand the first question, are you saying the customer is able to reprogram their device using flash boot but unable to use SCI boot? If this is the case, they should make sure they have correctly programmed their boot modes and boot mode select pins to switch between flash and SCI boot. Let me know if they have done this already or what exactly their issue is with SCI boot.

    To answer the second question, locking/securing the device does not block JTAG access by default, this only happens when the customer uses the JTAGLOCK setting which is also a permanent setting that should be used with caution. When the device is secure, all unsecure resources are still accessible via JTAG. The user must specify which flash and RAM sectors they want to secure so that these resources are inaccessible from JTAG or code running from unsecure memory when the device is secure.

    Thank you,

    Luke

  • Luke,

    I meant if customer just use zone 1 passwords, but leave all flash and RAM unsecure, then he is able to reprogram DSP device even boot mode is configured to flash boot. Because the device does not block JTAG access by default, the other user can read out all flash contents by connecting JTAG, I think it is not a safe way leaving all flash sectors and RAM unsecure.

    I have another question, if all flash sectors and RAM are secured, when software is executed from secured RAM, is it necessary to unlock device before programming secured flash sectors? According to TRM, the software from secured memory gets full memory access, so I think it is not necessary to unlock device before programming flash, it is correct?

    Regards,

    Luke

  • Hi Luke,

    Apologies for the confusion, I meant the original use case you referred to is fine if the customer wishes to change their security settings later. Simply programming the passwords however will not protect the flash and RAM sectors, you are correct.

    If you are programming secure flash via JTAG or an unsecured memory region, you must first unlock the device. However, any code running from secure memory can read or write to memory that is secured by the same zone without needing to unlock the device. This does not apply for the EXEONLY setting, however. This setting means that the code in this memory region can only be executed, and cannot be read from or written to.