The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

MSP430G2553: Selecting proper bsl protocol for MSP430G2553 and MSP430FR5872 in field

Part Number: MSP430G2553
Other Parts Discussed in Thread: MSP430FR5872,

Hello MSP430 Team,

What is the preferred way to determine which bsl protocol to use while working with the G2553 and FR5872 together. 

The customer is working on software that runs on a host processor that talks to the two processors (MSP430G2553 and MSP430FR5872 ).  The host processor will toggle the external pins to put one of the two processors in bsl mode, then try to upload the new image using the appropriate bsl uart protocol.  They are not working on the app software loaded on the MSP430G2553, MSP430FR5872 or on a custom bsl for those processors.  Those processors should be running the currently loaded application code 

For example

The V2.03 protocol is expecting a 2 part transaction.

Send sync: 0x80

Get ack: 0x90

Send change baud rate: 0x80, 0x20, 0x04, 0x04, 0x80, 0x8C, 0x02, 0x00, 0xF9, 0x57

Get ack: 0x90

Instead I send this valid V7 protocol message:

0x80, 0x02, 0x00, 0x52, 0x04, 0xXX, 0xXX

What is guaranteed to happen as a result of sending that string of bytes to the bsl that is expecting the 2 part transaction?

Does the first extra byte trigger the NAK since it only expects a 0x80 byte or will the bsl ingest the whole packet?  Will I get multiple NAKs?  Do I need to wait for a set amount of time before trying to send another command?

Summary of the issue:

The software will need to talk to both processors (different bsl protocols).  I want to try talking in one protocol every time.  If by chance I start with the correct protocol everything will progress fine.  If I start with the wrong protocol I need to be able to detect it and change my state machine. 


Is there an unprotected core command I should start with?

Is it better to try one bsl protocol over the other first?

Does the bsl for either processor always send a NAK type response or do I wait ‘X’ amount of time for no response and assume I should use the other protocol?

I would really appreciate any suggestions on this scenario. Thank you for your time and support.




  • Hello Kishen,

    This is a strange scenario here. My first question would be, aren't the two UART interfaces in separate UART lines? This would be the easiest way to tell them apart. Only use one protocol for the correct physical interface. UART lines are not typically shared between multiple devices like SPI and I2C are.

    As far as the differences in protocol, I see two major differences that could be exploited. the BSL on the G2553 requires the sending of 0x80 before sending additional bytes and it returns a 0x90 is an ACK. The BSL on the MSP430FR5872 device requires an 0x80 header as part of a command string, and will receive a 0x00 ACK header at the beginning of every Response string if the command is accepted without errors. One could send the newer format and check for the ACK to be 0x00 (or other error codes). If it is not, then reset device and switch to other BSL protocol (making sure to invoke BSL again after reset). Alternatively, you could send the 0x80 by itself and see if you receive the 0x90 ACK within a reasonable amount of time. Otherwise, reset and switch to other protocol.
  • Hello Jace,

    Thank you for your support. I really appreciate it.

    As for the initial query the software they are working on currently can execute the bsl process on the existing G2553 part. They have designed a new board with their app running on the new FR5872. The customer is working on a module that is installed on both of these hardware designs plus other products. That module uses the same bsl uart pins to talk to all of the customer application processors.

    So to sum it up the customer can send a command and wait for a response. They can make up the wait time since there is no specification for response delay. If they do not get a response try the other protocol ?

    Thank you for your time.

  • Kishen,

    That is my guess at the moment. As you said, there is no designated response time specification for these BSLs.

**Attention** This is a public forum