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.

MSP430FR2355: BSL application on MSP430FR2355

Part Number: MSP430FR2355
Other Parts Discussed in Thread: MSP-FET, MSP-EXP430FR2355

Please correct me if I'm wrong, but BSL password is not really a password, but the list of ISR addresses from 0xFFF0 through 0xFFFF. One can't simply pick a custom password.

So far I could get the BSL to work only with TI MSP-FET. The question is, if I have a MSP-FET, why do I care about BSL? I can simply program with RST/TEST pins.

I'm using application call to 0x1000 from P1.0 GPIO ISR.

I tried to run BSL with FTDI smart cable, CH340C and MSP Application UART1 that comes with MSP-EXP430FR2355.

Another weird thing is that MSP-FET UART-TXD is connected to P1.7, BSL TxD, and MSP-FET UART-RXD to P1.6, BSL TxD. Truly, one man's Tx is another man's Rx...

The BSL documentation is scattered across several PDFs and a couple of E2E threads. At one point I had 6 PDFs open!

Maybe there is a reason to it...

Any feedback would be appreciated.

  • from 0xFFF0 through 0xFFFF. One can't simply pick a custom password.

    It is 0xFFFE0 to 0xFFFF. Yes, it can't be changed random.

    So far I could get the BSL to work only with TI MSP-FET. The question is, if I have a MSP-FET, why do I care about BSL? I can simply program with RST/TEST pins

    If you can use JTAG, you can ignore the BSL, BSL just support to image update in future by a common interface like UART or I2C.

    I'm using application call to 0x1000 from P1.0 GPIO ISR.

    I tried to run BSL with FTDI smart cable, CH340C and MSP Application UART1 that comes with MSP-EXP430FR2355.

    Another weird thing is that MSP-FET UART-TXD is connected to P1.7, BSL TxD, and MSP-FET UART-RXD to P1.6, BSL TxD. Truly, one man's Tx is another man's Rx...

    What's the error do you see when you send BSL commend?

  • Gary,

    Thank you for the reply!

    The error I see on BSL-Scripter is [ACK_ERROR_MESSAGE]Header incorrect!

    Here is the script I'm using to test the connection

    MODE FRxx UART 9600 COM29
    VERBOSE
    RX_PASSWORD pass32_custom.txt
    // TX_BSL_VERSION
    // TX_DATA_BLOCK 0x8000 0x0200 Data_Read.txt
    // SET_PC 0x8000

    The custom password I use is the list of ISR addresses I mentioned in my post. It works fine, as it's verified with MSP-FET communication.

    I did go further with investigation, and here is a screenshot of communication between USB-UART bridge (CH340C in this case) and MSP-EXP430FR2355.

    I will continue mentioning only CH340C USB-UART bridge, but absolutely identical results are seen with FTDI TTL-232RG Smart Cable, FT4232, FT2232, MSP-EXP430FR2355 "MSP Application UART1" ports. I yet to try Silicon Labs bridges.

    The Reference waveform "A" shows "healthy" transmission with MSP-FET

    The Ch.1 shows transmission with CH340C USB-UART bridge. The COM port settings for CH340C are identical with MSP Application UART1 of MSP-FET.

    As you can see, the transmission words are being shifted, what looks like the EVEN bit is not being implemented. Or the STOP bit. Anyhow, the BSL prematurely replies on Ch.2.

    Here is a healthy transmission with MSP-FET (different scale, of course) on Ch.1 and reply on Ch.2. You can see the ACK bit.

    Proper reply from BSL is below.

    C:\ti\BSL-Scripter>BSL-Scripter script.txt
    ---------------------------------------------------------
    BSL Scripter 3.4.0.1
    PC software for BSL programming
    2023-Apr-20 09:08:07
    ---------------------------------------------------------
    Input file script is : C:/ti/BSL-Scripter/script.txt
    MODE FRxx UART 9600 COM48
    VERBOSE
            Verbose mode is now on!
    RX_PASSWORD pass32_custom.txt
            Read Txt File  : C:\ti\BSL-Scripter\pass32_custom.txt
            [80] [21] [00] [11] [30] [81] [30] [81] [1a] [81] [30] [81] [30] [81] [30] [81]
            [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81]
            [30] [81] [02] [81] [1f] [86]
            <80> <02> <00> <3b> <00> <60> <c4>
            [80] [21] [00] [11] [30] [81] [30] [81] [1a] [81] [30] [81] [30] [81] [30] [81]
            [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81] [30] [81]
            [30] [81] [02] [81] [1f] [86]
            <80> <02> <00> <3b> <00> <60> <c4> <00> <00> <00> <00> <00> <00> <00>
            BSL Password is correct!
    // TX_BSL_VERSION
    // TX_DATA_BLOCK 0x8000 0x0200 Data_Read.txt
    // SET_PC 0x8000

    Conclusion:

    It looks like the BSL-Scripter is not able to use other USB-UART bridges by setting the Parity or Stop bits properly, except for MSP-FET. Or maybe it's done intentionally? Unfortunately there are no PCs around with native COM ports to test. And If I have to create my own "programmer", I could simply instruct potential customer to use MSP-FET. It's costly, and reveals "the engine under the hood".

    My goal was ( or maybe still is) to give the user ability to field upgrade the hardware using just the stripped down BSL-Scripter or a custom application and a USB_UART bridge, that is already in the hardware box, aka "the product".

    My second question regarding use of MSP-FET came from an observation that non of the available to me USB-UART bridges worked with BSL-Scripter.

  • Update:

    CH340C (also FTDI smart cable, FT2232 and FT4232) do produce EVEN parity bit, when operated from Putty. Below is the screenshot.

    Ref B is "u", with odd number of "1"s, so the parity bit is generated 1, (right of the solid cursor)

    Ref C is "U", with even number of "1"s, so the parity bit is generated 0.

    Both SLAU665G and slau550AB talk about the parity, but there is no example with the usage of that optional property of MODE command. I tried "EVEN", "E", "0", "1", "2". - same result

    :

    :

    :

    And it worked....

**Attention** This is a public forum