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.

TMS320F2808: TMS320 Devices get locked accidently, reason is unknown

Part Number: TMS320F2808
Other Parts Discussed in Thread: TI-API

Hello,

after manufacturing test of boards some of the boards showed strange behaviour after the test sequences. In such cases, the two TMS320 devices became locked. The root cause is currently unknown.

In order to track the problem further, we implemented various CMSSCR read procedures into the test flow.

Before programming: 0050H

After programming: 0070H

This is true for all variants of this board and also for other boards using the same TMS320 device.

Now the question:

When reading the CSMSCR register of some other boards, we see CSMSCR values:

DSP1 = 0047H
DSP2 = 0041H


But they should be 0050H... What do these values mean? Is there a table describing the values further?


Many thanks in advance!

  • Hi Jan,

    Can you provide some details on what the test sequence involves and any specifics on when it fails during it? Are the CSM passwords programmed during the sequence?

    Notes from the datasheet:

    "Any brownout or interruption to power during erasing/programming could potentially corrupt the password locations and lock the device permanently."

    and

    "The 128-bit password (at 0x3F 7FF8 – 0x3F 7FFF) must not be programmed to zeros. Doing so would permanently lock the device."

    Best,

    Kevin

  • Hi Kevin,

    thanks for the quick reply. Since test sequence is done at our customer's (contract manufacturer) place  (they produce/test their customer's boards and I am part of the company that is providing the JTAG test equipment - GOEPEL electronic), I will involve the CM for more details.

    What I know is that the whole test sequence is part of a functional test system that includes a JTAG test and programming equipment. Somewhere in the middle of the sequence we do a Boundary Scan test and afterwards DSP programming. Many test cycles are resulting ok, just a minor part shows the problem and we need to find out what is causing the trouble since the boards are expensive and replacing the DSPs is not allowed for security reasons.

    So, we were hoping to get more information based on the values that are read from the CSMSCR register (0041H and 0047H).

    Yesterday I was browsing the forum for other and maybe similar cases but did not find much useful information. We understand that such behaviour most likely is caused by a interrupting situation during erase or programming of the devices. And we are aware of the two facts that you mentioned above... Also, afaik, there are no passwords programmed during that test sequence (will double check).

    What makes the situation a bit more strange is that both DSPs are mocated in the same scan chain, together with TI documentation (using TI-API functions) we found a way to handle this situation and program both devices after each other. Strange is that both devices seem to be locked (at least on one board DSP1 showed the 0041H value, the other DSP2 showed 0047H). Maybe that information can lead to the root cause?

    Best Regards

    Jan

  • CSMSCR register is described in SPRU712H. For your situation, only bit0 which indicates whether the device is secure (or not) is relevant. As you can see, that register has only 2 useful bits.

  • Hi Hareesh,

    I am aware of that document and was hoping that the reserved bits provide addtionional information; or the values provided (0041H and 0047H)...

    Best Regards

    Jan

  • Hello,

    can anyone confirm, that the reserved bits (multiple locked devices provide 0041H or 0047H codes when reading the CSMSCR), have a specific meaning which may help in resolving the question why the devices got locked?

    Many thanks in advance!

    Jan

  • Hi Jan,

    Sorry for the delay. We're working on gathering more information on the CSMSCR register bits in order to provide you a good answer.

    Hareesh or I will get back to you when we have more information to provide. Thank you for your patience.

    Best,

    Kevin