• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1183 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

280049 can't operate independently after encryption

Hugh xiao
Prodigy 171 points


hello

 After using 280049 DCSM (only Z1 area for encryption), connect the emulator,  decrypt it in On-chip Flash, load program can run.

But after disconnecting the simulator, the power-on can not work properly, and the DSP has been in the reset state.

Analysis reasons: 1. Decryption problem

2. Boot loader  Problem

For 1 decryption,  the decryption function DCSM_unlockZone 1CSM (& PasswordKey) in TI driver lab is called directly, and the problem remains.

For 2 Bootloader, the default boot mode of hardware, that is, gpio32 and gpio24, is high, so Z1otp-GPREG1(0x7800C) is configured as 0xFFFFFFFF，Z1otp-bootctrl(0x7801E)  is 0xFFFFFFFF

1otp-GPREG1 (0x7800C) is configured as 0x5AFFFFFF, Z1otp-bootctrl (0x7801E) is 0xFFFFFF02. The problem remains.

Do you have any other possible reasons? Thank you.

  • 0
    TI__Guru** 115881 points

    Hi,

    But after disconnecting the simulator, the power-on can not work properly, and the DSP has been in the reset state.

    What do you mean by DSP is in reset state? Do you see XRSn pin low all the time or toggling high/low ?

    With CCS connected, you could also emulate the standalone boot by configuring the key as 0xA5 in EMU-BOOTPIN-CONFIG (location 0xD00) and debug it.

    - power up the device

    - connect the CCS

    - Update location 0xD00 with value 0xA5FF1820 (GPIO24 and GPIO32 as BOOTPIN).

    - Issue debugger reset (in CCS)

    - Run the CPU.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 171 points
    Hi Vivek,
    thanks for your reply.
    Maybe my description is not very clear.
    1、This problem occurs only after encryption, and the unencrypted DSP does not have this problem. And for the encrypted DSP I modified EMU-BOOTPIN-CONFIG as you suggest, the problem remains.
    2、For the encrypted DSP board,I connect the emulator and decrypt it by on-chip-Flash, It can run. but disconnect the emulator and re-power it can't run.
    3、 the DSP has been in the reset state.-- the XRSn pin is reset with 7.8ms cycle (low level)

    Regards,

    Hugh
  • 0 in reply to Vivek Singh
    Prodigy 171 points
    Hi Vivek,
    My question is the same as this one.
    e2e.ti.com/.../2852527
    If there is any progress, please let me know.
    Thank you.
  • 0 in reply to Hugh xiao
    Prodigy 171 points
    Hi Vivek,
    I see that the following problems has been solved:
    e2e.ti.com/.../768778
    but My problem is different from this one.
    I've done more tests. Before encrypting the password area( DCSM_OTP_Z1_PSWDLOCK is 0xFB7FFFFF ), the encrypted program can run normally, but when encrypts the password area(write 0xFB7F5555 DCSM_OTP_Z1_PSWDLOCK), the program can't run.
    I use a new DSP , write 0xFB7FFFF5 in DCSM_OTP_Z1_PSWDLOCK, the problem is solved.
    Comparing the chips, the first problem one is TMS320F280049MPZS, and the second one is the TMS320F280049CPZS.
    So I want to confirm whether this problem is caused by the sample of TMS320F280049MPZS or by the value 0xFB7F5555 written in DCSM_OTP_Z1_PSWDLOCK ?
    By the way, the default values of the address 0x780012 of the two chips is also different. the fist is 0xFFFFFFFF the second one is 0x7FFFFFFF.
  • 0 in reply to Hugh xiao
    TI__Guru** 115881 points

    Hi Hugh,

    Sorry for late reply.

    I use a new DSP , write 0xFB7FFFF5 in DCSM_OTP_Z1_PSWDLOCK, the problem is solved.

    Can you explain how are you using the password encryption method? Please note that PSWDLOCK only impact the visibility of password but does not change security aspect. As long as you are not reading the password values, it should not impact anything.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Guru** 115881 points
    Hi Hugh,

    Do you have any further update on this issue?

    Vivek Singh
  • 0 in reply to Vivek Singh
    Prodigy 171 points
    Hi Vivek,

    Sorry for late reply.

    My encryption configuration is:
    RAM and Flash are encrypted, and the password area is not visible\read(write 0xFB7FFFF5 in DCSM_OTP_Z1_PSWDLOCK), and only DCSM_OTP_Z1 is used，Other DCSM OTP s use the default configuration and have not changed

    When I used TMS320F280049CPZS and TMS320F280049PZS , there were no problems mentioned above.

    The problem only appeared at TMS320F280049MPZS and write 0xFB7F5555 in DCSM_OTP_Z1_PSWDLOCK(The correct value is 0xFB7FFFF5)

    So I want to confirm whether this problem is caused by the sample of TMS320F280049MPZS or by the value 0xFB7F5555 written in DCSM_OTP_Z1_PSWDLOCK ?
  • 0 in reply to Hugh xiao
    TI__Guru** 115881 points
    Hi Hugh,

    PSWDLOCK is only 4 bit hence other values should not matter so programming 0xFB7F5555 in PSWDLOCK should not cause any issue. But I am curious to know why are you programming different value on this? If you have fresh TMS320F280049MPZS part, can you check the default value in address range 0x78000 to 0x7802F and let me know.

    I am trying to find more info on TMS320F280049MPZS part and will get back to you early next week.

    Regards,

    Vivek Singh
  • 0 in reply to Vivek Singh
    Prodigy 171 points

    Hi Vivek,

    I programming 0xFB7F5555 in PSWDLOCK by mistake

     On TMS320F280049MPZS , the default values of the address 0x780012 is 0xFFFFFFFF , TMS320F280049CPZS and  TMS320F280049PZS is 0x7FFFFFFF.

    The other addresses are the same.

  • 0 in reply to Hugh xiao
    TI__Guru** 115881 points

    Hi Hugh,

    Can you double check that 280049M is TMS part and not TMX? Look like "M" was very early part and not supported anymore. It may be possible that you have a very early sample. That also explains why you have different default value on that part.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 171 points
    Hi Vivek ,

    I checked the chip. The complete text on it is F280049MPZS, no TMS or TMX, but this is really an early sample.

    You mean the problem is caused by the sample?
  • 0 in reply to Hugh xiao
    TI__Guru** 115881 points
    I would think so since it does not even have USER OTP programmed differently.