• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 781 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC430F5133: MSP430_Secure() fails after clearing JTAG signature

Bob Lawson
Prodigy 190 points
Part Number: CC430F5133
Other Parts Discussed in Thread: UNIFLASH, MSP-FET, MSPBSL

I'm working on a programming tool that does a sequence very similar to the sequence shown here:

After successfully programming the CPU my tool called MSP430_Secure() and everything succeeded.  I verified the JTAG interface was disabled in both CCS and using the UniFlash tool.

Next, I wrote some code that used the BSL interface to re-enable the JTAG interface using the RESET/TEST/TX/RX lines to the CPU.  The sequence I used was:

1) Send the "Rx Password" BSL command with all 0xFF's for the password. This causes a mass erase of the device. I verified a successfully Ack message is received afterwards.

2) I wanted to see what the JTAG signature bytes in 0x17FC-0x17FF were currently set to, so I sent a "Tx Data Block" BSL command and verified the returned value was neither 0x00000000 or 0xFFFFFFFF.  I can't remember what the actual value returned was -- it was something like 0x55555555 or 0xC5C5C5C5.

3) I sent a "Rx Data Block" command to write 0x00000000 to addresses 0x17FC-0x17FF.  This also returned a successful Ack.

After completing these steps, the JTAG interface worked again.  I could read out the device using UniFlash or download and debug code via CCS.

Here's the problem ...

I tried reprogramming the CPU again using my custom tool which calls MSP430_Secure() at the end, but now the MSP430_Secure() call fails with error "Could not secure the device".

If I try to secure the CPU again with UniFlash, I get the same error.

I saw a discussion here (http://microcontrollers108.rssing.com/chan-64320859/all_p1249.html) where someone mentions that MSP430_Configure() might need to be called with first parameter set to CONFIG_JTAG_LOCK_5XX, but all attempts with that failed and there wasn't any documentation to help explain this.

What am I missing? What do I need to write through the BSL commands to get the CPU back to a state where I can once again program the CPU and disable JTAG via MSP430_Secure()?

  • 0
    TI__Mastermind 36765 points

    Hi Bob

    What's the host do you use to communicate with the BSL? If it is a PC, I will recommend you to use the BSL scripter and we have give the demo codes for the JTAG lock and unlock demo. For more detail you can refer to the user's guide page 41 

    Best regards

    Gary

    MSP430_Secure

  • 0 in reply to Gary Gao
    Prodigy 190 points

    I use a PC, but I'm working with custom hardware so I can't run BSL Scriptor.

    I see from the script that I need to run these BSL commands:

    MASS_ERASE
    RX_PASSWORD
    RX_DATA_BLOCK JTAG_UNLOCK.txt

    where JTAG_UNLOCK.txt is a 4 byte write of 0x00's to address 0x17FC.

    I have a scope connected to the Tx/Rx UART lines and this is exactly the sequence I have implemented and for each command the BSL is returning a successful Ack.

    Afterwards, when I connect my MSP-FET programmer to the JTAG connector on our programming jig, I can download and run code from the CCS debugger, but if I try to run my programming utility and call the MSP430_Secure() API, I still get the "Could not secure the device" error.

    Can you look at the MSP430_Secure() source code and tell me why it might fail with this error code?  As I said earlier, even UniFlash is failing to secure the CPU.  It also gives the same error message.

    The version of the MSP430.DLL that I'm using is 3.13.0.1

  • 0 in reply to Bob Lawson
    TI__Mastermind 36765 points

    Hi Bob

    Have you try the Flash_LockJtag demo?

    What's your custom hardware's function? Do you have the schematic of it?

    Do you have a MSP-FET?

    Best regards

    Gary

  • 0 in reply to Gary Gao
    Prodigy 190 points

    Yes, I have an MSP-FET.  That is the JTAG interface I've been using with UniFlash to test locking the CPU via MSP430_Secure().

    Can you share with me the source code for MSP430_Secure() in the MSP430.DLL?  I'd like to understand how that function can fail.

    The Flash_LockJtag demo does the following:

    MASS_ERASE
    RX_PASSWORD
    RX_DATA_BLOCK JTAG_LOCK.txt

    where JTAG_LOCK.txt is a 4 byte write of 0xAA's to address 0x17FC.

    I modified my tool to do this sequence and what I get on my scope for the RX_DATA_BLOCK command is:

    Transmit to BSL:  0x80 08 00 10 FC 17 00 AA AA AA AA 29 BD

    Receive from BSL:  0x00 80 02 00 3B 01 41 D4

    The BSL manual says error 0x01 is "Memory (for example, flash or FRAM) write check failed. After programming, a CRC is run on the programmed data. If the CRC does not match the expected result, this error is returned."

    If I read the bytes at 0x17FC, they are all zeros.  I assume there must be some operation I'm missing to "erase" those bytes to get them back to 0xFFFF before they can be written again to 0xAAAAAAAA.  Maybe this is why MSP430_Secure() fails also (even though it is using the MSP-FET JTAG interface and not BSL commands through a UART.

    I also tried writing FF's to 0x17FC with this sequence, but of course that fails also:

    Transmit to BSL:  0x80 08 00 10 FC 17 00 FF FF FF FF 73 3A

    Receive from BSL:  0x00 80 02 00 3B 01 41 D4

    What BSL commands can I send to get the JTAG signature at 0x17FC back to 0xFFFFFFFF?

    The custom board I'm working on is a fob and our programming jig interfaces with it through a bed-of-nails set of pins that give us access to the RESET, TEST, RX and TX lines needed for BSL communication.

    I don't have permission to share those schematics on a public forum.

  • 0 in reply to Bob Lawson
    Guru 92251 points

    Bob Lawson said:
    Can you share with me the source code for MSP430_Secure() in the MSP430.DLL?  I'd like to understand how that function can fail.

    The source is available in the MSPDS-OPEN-SOURCE link on http://www.ti.com/tool/MSPDS.

    Note that the latest source available is slac460y which contains Rev 3.13.0.001, whereas in CCS 9.2 uses the later revision Rev 3.14.0.000.

    For MSP430_Secure() I think the call tree is:

    MSP430_Secure() in DLL430_v3\src\DLL430_capi.cpp -> DLL430_OldApiV3::Secure() in DLL430_v3\src\DLL430_OldApiV3.cpp -> DeviceHandleMSP430::secure() in DLL430_v3\src\TI\DLL430\DeviceHandleMSP430.cpp

  • 0 in reply to Chester Gillon
    Prodigy 190 points

    I'm still struggling to get all of the components installed and built to be able to try to debug this.  I'm not sure if I'm going to be able to get it built successfully.

    Can you please respond to this observation from earlier?

    "If I read the bytes at 0x17FC, they are all zeros.  I assume there must be some operation I'm missing to "erase" those bytes to get them back to 0xFFFF before they can be written again to 0xAAAAAAAA.  Maybe this is why MSP430_Secure() fails also (even though it is using the MSP-FET JTAG interface and not BSL commands through a UART."

    Why doesn't a mass erase command issued to the bootloader cause the bytes at 0x17FC to erase back to the 0xFFFF state?  What do I need to send to the bootloader to erase them?

  • 0 in reply to Bob Lawson
    Guru 92251 points

    Bob Lawson said:
    Why doesn't a mass erase command issued to the bootloader cause the bytes at 0x17FC to erase back to the 0xFFFF state? 

    The JTAGLOCK_KEY bytes at 0x17FC are in the upper part of the "BSL 3" flash segment from 0x1600 .. 0x17FF. The BSL running from the BSL flash segment is unable to erase just the JTAGLOCK_KEY bytes without also erasing part of the BSL itself.

    The BSL430_massErase() function in MSP430BSL_1_01_00_01\CCS_BSL_Source\API\BSL430_API.c (downloaded from MSPBSL_CustomBSL430) sets the MERAS + ERASE bits:

        FCTL1 = FwRamKey + MERAS + ERASE;           // Set Mass Erase bit

    The CC430 Family User's Guide explains that setting MERAS and ERASE bits doesn't erase the BSL segments:

    Bob Lawson said:
    "If I read the bytes at 0x17FC, they are all zeros.  I assume there must be some operation I'm missing to "erase" those bytes to get them back to 0xFFFF before they can be written again to 0xAAAAAAAA.

    Looking at the MSPDS-OPEN-SOURCE code and MSPBSL_CustomBSL430 code I can't see any existing mechanism to erase just the JTAGLOCK_KEY bytes at 0x17FC. To erase the JTAGLOCK_KEY bytes you would have to do something along the lines of:

    a. Read the existing contents of BSL 3 segment from 0x1600 .. 0x17FB.

    b. Erase the entire BSL 3 segment.

    c. Reprogram the previous contents of the BSL 3 segment from 0x1600 .. 0x17FB saved above.

    Notes:

    - Trying the above with the BSL would first requiring the downloading of a RAM based BSL, as the BSL 3 segment contains part of the flash BSL program.

    - To erase the BSL 3 segment when using the MSP-FET JTAG interface you might have to use MSP430_Configure(UNLOCK_BSL_MODE,...) to first unlock the BSL segment. I haven't tested if the BSL is locked by default.

    - The MSPBSL_CustomBSL430 comes with some pre-built BSL images in MSP430BSL_1_01_00_01\Released_BSL_Images\CC430_Family in TI text format. Rather than erasing just the JTAGLOCK_KEY bytes, it might be simpler to erase all of the BSL segments and then program the complete BSL image using MSP430_ProgramFile() via the MSP-FET JTAG interface. This might change the BSL version in flash.

  • 0 in reply to Chester Gillon
    Prodigy 190 points

    This seems to be getting overly complicated.  I think I need to back up and reconsider what we're doing.

    What I'm trying to do is:

    A) Create a programming tool that uses the MSP430.dll APIs to program the CPU via the JTAG interface.  (Since our programming jig also has the circuits for programming the CPU via BSL, I could abandon the MSP430 APis entirely and use BSL commands only, but that would be more work for me.)

    B) After the CPU is programmed, the JTAG interface should be locked out to avoid code read out by a hacker.  It doesn't matter to me if this is done using an MSP430 API call such as MSP430_Secure() or if the code we program into flash does something itself on its first boot to disable JTAG.

    C) I want the option to be able to mass erase the CPU via the BSL and start all over in case we find a bug in our code later.

    Currently, I can do steps A, B and C, then start again with step A but on the second attempt at running step A, the MSP430_Secure() call fails every time as I explained before.

    Is there an alternative solution to do what I'm trying to do?  Should I be avoiding MSP430_Secure() and using some other means to disable JTAG?

  • 0 in reply to Bob Lawson
    Guru 92251 points

    Bob Lawson said:
    This seems to be getting overly complicated.  I think I need to back up and reconsider what we're doing.

    OK, I understand what you are trying to do. I was trying to understand what was causing MSP430_Secure() to fail based upon the public information for the CC430 devices, MSP430.dll source code and BSL source code.

    As for the JTAG protection:

    a. The JTAGLOCK_KEY bytes at addresses 0x17FC..0x17FF which lock the JTAG access if have any value other 0x0 or 0xFFFFFFFF.

    b. When the flash BSL is programmed into a CC430 device during TI manufacture the JTAGLOCK_KEY is set to 0xFFFFFFFF, i.e. left in the flash erase state.

    c. MSP430_Secure() for a CC430 works by programming a value into JTAGLOCK_KEY bytes which locks the JTAG. Looking at the slac460y code the value written to the JTAGLOCK_KEY has the default value of 0xCACACACA, which is the initial value of the JTAGLock5xx variable in slac460y\Bios\src\hal\macros\Configure.c. The MSP430_Configure (CONFIG_JTAG_LOCK_5XX) can be used to change the value which MSP430_Secure() writes to JTAGLOCK_KEY.

    d. After attempting to program the JTAGLOCK_KEY bytes, MSP430_Secure() checks for the JTAG being locked by determining if the device is in JTAG bypass mode or not.

    e. Since MSP430_Secure() only performs a flash programming operation, it can only change bits from the erased '1' state to '0'. Based upon your steps, on the second attempt at step A) the JTAGLOCK_KEY bytes will be 0x0, following using the BSL to unlock the JTAG, and therefore MSP430_Secure() will fail to re-lock the JTAG.

    Bob Lawson said:
    Should I be avoiding MSP430_Secure() and using some other means to disable JTAG?

    Based upon my analysis above I don't think avoiding the use of MSP430_Secure() will help; the issue is that to allow a 2nd successful attempt to disable JTAG the BSL 3 segment containing the JTAGLOCK_KEY bytes must be first erased. Since the BSL 3 segment also contains part of the BSL program, after erasing the BSL 3 segment the BSL needs to be re-programmed.

    Bob Lawson said:
    (Since our programming jig also has the circuits for programming the CPU via BSL, I could abandon the MSP430 APis entirely and use BSL commands only, but that would be more work for me.)

    Perhaps your A) could be changed to:

    1 Read the contents of the JTAGLOCK_KEY bytes.

    2. If the JTAGLOCK_KEY are currently a value other than 0xFFFFFFFF then re-program a TI-BSL image:

    - Call MSP430_Configure (UNLOCK_BSL_MODE, ENABLE) to unlock the BSL memory.

    - Call MSP430_Erase(ERASE_ALL, 0, 0) which will erase the main, information and BSL memory. Not sure if you have any data in the information memory which needs to be preserved.

    - Call MSP430_ProgramFile() to program a pre-built TI-BSL image.

    3. Continue to program the application.

    Apologies that the above is a bit vague, but I am not a TI employee and don't currently have hardware with a BSL and JTAG connection to try the above proposed change.

  • 0 in reply to Chester Gillon
    Prodigy 190 points

    Thanks you very much for taking the time to give such a detailed response when you don't even work for TI.

    I think your proposed solution may work for me.  I will give it a try and post my results.

    Bob

  • 0 in reply to Bob Lawson
    Prodigy 190 points

    I verified your solution worked.

    Again, thanks so much for taking the time to help me.

    Bob