• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 2046 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.

F28335: can't connect after CSM lock even with wait-in-reset

William Fang
Prodigy 50 points


Emulator: XDS100v2

 * The JTAG nTRST Boot-Mode = "Enabled - EMU1 is high, EMU0 is low"
 * The Power-On-Reset Boot-Mode = "Enabled - EMU1 is high, EMU0 is low"

Boot Mode: Jump to flash (GPIO84~87 either used as outputs or left floating in my application)

When I first programme the chip with password active I can debug just fine, including when I reset through the JTAG. But the moment I power cycle the device or force a lock with CSMStsCtrlReg.FORCESEC=1 I can't get back in. I know wait-in-reset is in effect because as long as the emulator is connected during POR the LEDs on my device stop flashing. I have set the same password in the Flash options page to no effect.

The only way I can get out of this bind at the moment is to force a flash erase on sector A through my own bootloader when I need to unlock. But as it is I can't effectively develop my code without leaving the passwords blank. Murphy dictates that at some point I am going to forget to compile a .out for production release with the CSM active.

  • 0
    Prodigy 50 points
    Oh and this is with CCS 5.5.
  • 0
    Guru 192875 points

    Hi Will,

    By Wait-in-reset: Did you change the Boot mode to : Wait mode and then Unlock the device. If not then try the same, works for me everytime :)

    Regards,
    Gautam

  • 0 in reply to Gautam Iyer
    Prodigy 50 points
    Can't do anything about the Boot mode, I got the BGA version and the pins were not routed out so I can't get to them.
  • 0 in reply to William Fang
    TI__Guru** 115581 points

    Hi William,

    As Gautam mentioned, you must use the Wait Mode by changing the BOOT MODE pin setting to be able to connect to CCS after security passwords are programmed. If you cannot change the BOOT MODE pin setting then you have to disable the ECSL in start of your application code. For this you need to write 64bit password in KEY0/1 register(please refer the DCSM section in TRM for more detail). After this you should be able to connect to CCS while device is still secure (only ECSL will get disbale).

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 50 points

    Ok, adding as suggested ECSL disable sequence immediately after entering my custom bootloader. Now I can re-flash and access a locked chip anytime.

    The passwords only needs to be added to the GEL file, it was not even necessary to add wait-in-reset to the JTAG settings! The password field under the flash settings page was misleading and utterly useless.

    I also experimented with different combination of stuff (all with Boot mode = Jump to flash).

    Turns out:

    • If the low key is blank in flash, having wrong low keys in the GEL:Unlock_CSM() but correct high keys will unlock the CSM and allow you to read the full key, even through you can't flash the chip.
    • If low key is written in flash and the Unlock_CSM() has the high key (low keys are 0xFFFF), after entering my application the status register will report the CSM as unsecure. Even though as expected I cannot read anything through the JTAG.
    • No unlocking/flashing can work if the ECSL disable code is not added.

    We can really use better some documentation regarding the behavior of the CSM. Another inconvenience is that you need to modify to GEL's password setting to match the one in your project, but the GEL is not part of your project but part of the CCS installation.

  • 0 in reply to William Fang
    TI__Guru** 115581 points

    Hi William,

    Could you give some more detail on points below -

    If the low key is blank in flash, having wrong low keys in the GEL:Unlock_CSM() but correct high keys will unlock the CSM and allow you to read the full key, even through you can't flash the chip.

    What do you mean by "low key is blank in flash"? Is is not programmed and left as ALL_1 (0xFFFF_FFFF/0xFFFF_FFFF) ?

    If low key is written in flash and the Unlock_CSM() has the high key (low keys are 0xFFFF), after entering my application the status register will report the CSM as unsecure.

    Again, when you say low key is written in flash, does it mean low keys are programmed with value other than ALL_1 (0xFFFF_FFFF/0xFFFF_FFFF)? Can you double check that unsecure status is set even though low keys are entered as ALL_1.

    Regards,

    Vivek Singh