• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 349 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.

MSP430FR5739: BSL Invocation and communication - odd responses

Graham Finney
Prodigy 10 points
Part Number: MSP430FR5739

Hello,
I am in the process of developing for updates of a MSP430 from a host processor (an iMX, but that's not relevant).

Using the GPIO on the iMX, I attempt to put the MSP430 into bootloader mode using the RST/TST sequence. I then proceed to send the RX-password command along with the password, derived from the first 16 words of the vector table, as specified. I receive no response, from which I can only infer that the password is incorrect (the datasheet for this variant states that no response is expected for an incorrect password). I ahve checked the CRC and it appears correct (would it have bee ACKed with a 0x52 response in thet case?).

The 16 words (in little-endian) in the vector table are:

@FFE0
30 EE 0A F0 0A F0 0A F0 0A F0 0A F0 0A F0 C0 EF
90 EF 0A F0 90 ED 0A F0 0A F0 0A F0 0A F0 BA EC
q

We have also tried reversing the endianness, for completeness, to no avail.


The get-password messages was as follows.
0x80, 0x21, 0x00, 0x11, 0x9E, 0xED, 0x78, 0xEF,
0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF,
0x78, 0xEF, 0x2E, 0xEF, 0xFE, 0xEE, 0x78, 0xEF,
0xFE, 0xEC, 0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF,
0x78, 0xEF, 0x28, 0xEC, 0xA1, 0x28

The waveform is as shown here. Note that  here, RX is the data received by the MSP430.

No response is received, as can be seen.

Significantly, there is data being sent from the host following the BSL invocation, but the RX line is not changing. The host has been checked, and it is not holding the line high. If the BSL invocation is omitted, the line is free to move and data is visible. To all appearance, the RX line is being held high by the MSP430.

One observation was that if the BSL invocation didn't occur, but a valid message was sent to the BSL, a response is received, albeit before the message is completed. I doubt this has any relevance, but it is curious. The response looks like a valid ACK (header incorrect).

We have exhausted all avenues for this puzzle.

Can anyone help?

 

Thanks

Graham

  • 0
    TI__Genius 13315 points

    Hi Graham,

    It will take a few time to review the case. I will reply as soon as I get the conclusion.

    B.R.

    Sal

  • 0
    Expert 1940 points

    Have you double and triple checked first that you are transmitting on the correct pins? On your device, BSL RX is on port 2.1 and BSL TX is on port 2.0. This is in the datasheet, Table 6-3, "BSL Pin Requirements and Functions". Also, the BSL is configured to 9600 baud with EVEN parity, 8 data bits and 1 stop bit (3.1.1 of SLAU550).

    As a test to make sure the interface is setup correctly, you should try a different command that will actually send a response; "TX BSL Version" will respond with a core response of 0x04 (BSL locked) if the BSL is locked, or the BSL version if it is unlocked. In your case, if you send an incorrect password, there is no response and the device is erased. If you send the same password again on a blank device, that is also incorrect as the password to unlock a blank device would be 32 bytes all set as 0xFF so the device is erased again with no response.

  • 0
    TI__Genius 13315 points

    Hi Graham,

    Sorry for the late respnse, and I think Seth gives a great clarification.

    Meanwhile, you can refer to https://www.ti.com/lit/ug/slau550ab/slau550ab.pdf :

    And, the BSL password is low bit pass first; CRC code should contain CMD+Data.

    Graham Finney said:
    The get-password messages was as follows.
    0x80, 0x21, 0x00, 0x11, 0x9E, 0xED, 0x78, 0xEF,
    0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF,
    0x78, 0xEF, 0x2E, 0xEF, 0xFE, 0xEE, 0x78, 0xEF,
    0xFE, 0xEC, 0x78, 0xEF, 0x78, 0xEF, 0x78, 0xEF,
    0x78, 0xEF, 0x28, 0xEC, 0xA1, 0x28

    As this code, it is not get-password messages, rather than it is a command that unlock device, which is not match your password lists:

    Graham Finney said:
    @FFE0
    30 EE 0A F0 0A F0 0A F0 0A F0 0A F0 0A F0 C0 EF
    90 EF 0A F0 90 ED 0A F0 0A F0 0A F0 0A F0 BA EC
    q

    So, as Seth description, a mass erase will occurs.

    B.R.

    Sal

  • 0 in reply to Seth Jackson
    Prodigy 10 points

    Hi,

    I tried to reply once, but my  reply seems to have disppeared. I have tried what you suggest with no positive result. I am about look at what Sal says, and see what I can learn from that. At the moment, I am having intermittent debug problems, hense the delay in my response.

    Thanks

    Graham

  • 0
    Prodigy 10 points

    Hi,

    Sorry I didn't notify you earlier. Following your advice, I have corrected my code and this has solved the problem.

    Many thanks

    Graham

**Attention** This is a public forum