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.

Secure boot OMAPl138 + Target connection problem

Other Parts Discussed in Thread: OMAPL138

 

Hi

Iam currently using the OMAPl138 containing secure boot version.Iam getting the error "Connect to PRSC failed". when i tried to connect CCS to the device using XDS100v2

Since secure boot version has some constraints,is this error related to the above chip? Is any software lock have to be introduced before CCS target connection

Kindly advise me

Regards

Vijayabharathi C

 

  •  

    Iam currently using the CCS version 4.1.3.,my chip chip revision is 2.0.We verified that CCS along with the XDS100v2 already works fine with the Rev1.1 OMAPl138 chip.

    For this 2.0 revision, do i had to add any upgrades in the CCS? or any higher version CCS will only support the Rev 2.0 chips? Kindly Advise me

    Regards

    Vijayabharathi C

  • Hi

    We replaced non-secure omapl138 chip in our custom board. Now we could able to connect to the JTAG. I am sure that this secure option is only keeping the JTAG in disabled state.debug tap of ICEPICK is disabled on a secure device by default and the device will have no JTAG access by default

    If TI has any sample snippet or file to unlock this secure option,Kindly provide us or suggest us how to unlock the device

    Regards

    Vijayabharathi C

  • The only way to unlock the JTAG to begin a typical CCS-based development is to boot the device and provide commands in the boot image to unlock the JTAG access.  From the package provided here, you should read the security user's guide and look at the Flash and Boot utilities that are provided.  There is a tool included there that lets one boot via the Serial port of their PC, which is probably the easiest option to boot the device, assuming your platform has serial port and can be configured for the UART boot mode.

    Since the security aspect of things only come into play when you want to boot the device (and not when your program is actually running), I would recommend developing prototype boards with the non-secure version of the device so these can be used for application and system development without the complications of having to unlock the devices.  Then the boot procedures can be later be finalized and tested on actual secure devices.

    Regards, Daniel