MSP430FR2355: mspdebug on linux using UART BSL - unable to invoke BSL entry sequence

Hi Gary,

Your hardware connections seem fine between the CH340G and the MSP430FR2355. 

Please see Section 3.3.2 Hardware BSL Invocation of the MSP430 FRAM Devices Bootloader (BSL) User's Guide for information on the BSL entry sequence for this device and issues that are causing incorrect hardware BSL invocation.

www.ti.com/.../slau550z.pdf

I poked around a little more and noticed that the hardware connections were wrong; mspdebug's man page calls out connecting RTS of the serial chip to the TEST pin of the MSP430. It turns out that the breakout board I have from Sparkfun doesn't have the /RTS pin of the CH340G routed (Figure 1). I soldered a wire onto pin 14 of the CH340, and I see the correct BSL invocation as seen in Figure 2 with mspdebug.

Figure 1:

 
Figure 2:

After fixing the BSL entry sequence, now the MSP430FR2355 won't respond to the entry sequence as can see in the output below. (The MSP430FR2355 times out and when mspdebug tries to initiate a mass erase, mspdebug gets a bad ack character: 54.):

$ mspdebug rom-bsl -d /dev/ttyUSB0
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

rom_bsl: failed to receive reply: Connection timed out
rom_bsl: failed to receive reply: Connection timed out
rom_bsl: sync failed
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
rom_bsl: bad ack character: 54
rom_bsl: failed to receive reply: Connection timed out
rom_bsl: sync failed
rom_bsl: failed on command 0x18 (addr = 0xfffe, len = 0xa506)
rom_bsl: initial mass erase failed
rom_bsl: failed to unlock

To check to see if this was an issue with my serial device or the launchpad, I tested with an older MSP-EXP430G2 launchpad (MSP430G2553). I was able to use mspdebug to enter the device with BSL and UART:

$ mspdebug rom-bsl -d /dev/ttyUSB0
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
Chip ID data:
  ver_id:         5325
  ver_sub_id:     0000
  revision:       00
  fab:            60
  self:           0000
  config:         00
  fuses:          00
Device: MSP430G2xx3
    

Does the MSP430FR2355 not respond to the BSL sequence using a serial device? The BSL Signature is set perform a mass erase on wrong BSL password, and JTAG/SBW is also unlocked.

Hey Gary,

Can you confirm whether this BSL entry sequence works on another FRAM device or Launchpad if you have one?

We are investigating this issue internally and myself or another team member will reply to you with more details tomorrow. 

Aaron,

I can confirm whether or not that will work next week; I don't have any extra FRAM devices on hand at the moment.

Hi Gary, 

No worries, good to know.

Something good to check is ensuring that there is enough delay from BSL entry until the first command is sent. For the MSP430FR2355, the device requires at least 300 ms from the BSL entry invocation sequence until the BSL is ready to receive the first command. This is taken from section 3.6 of the MSP430 FRAM Devices Bootloader (BSL) User's Guide: https://www.ti.com/lit/ug/slau550z/slau550z.pdf

I tried on the launchpads for the MSP430FR2311 and the MSP430FR4133 and got the same results.
 
It seems as if the entry sequence is having an effect on the device, because the program that is running freezes when the entry sequence begins. (e.g. if there's a blink program, the LED will stay on after the entry sequence is invoked.)
 
Figure 1 shows an oscilloscope capture of MSP430FR2355 after sending the BSL sequence and the first command. After about 550 ms, mspdebug sends the first command on P1.6, but there's no reply on P1.7, so mspdebug times out. P1.6 is low for about 820us.

Figure 1.

 
I did find a previous thread on e2e about FR devices and mspdebug, but I can't tell if the FR2355 device is ignoring the BSL entry sequence: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/199601?tisearch=e2e-sitesearch&keymatch=mspdebug%2520bsl

What else can I do to continue to troubleshoot this?

Hi Gary,

Can you capture the MSP RXD line and expand it to show what it is doing where you have it circled in red?

Hi Gary,

Could you also clarify what baud rate you are using and what type of command is being sent by mspdebug?

Figure 1 shows the red oval expanded.

Figure 1. FR2355 Red oval from previous post expanded

When I run this on the G2553 device, there's some sort of response (NACK?) on the MSP TXD line before sending some commands. See Figure 2.
According to mspdebug output, this also does the following: 0x1e failed command, perform mass erase, send password. The green oval is expanded in Figure 3.

Figure 2. MSP430G2553 BSL entry sequence and some commands

Figure 3. MSP430G2553 green oval from Fig 2 expanded

Back to the FR2355 device. After a few time-outs, mspdebug holds P1.6 (MSP RXD) low for 840 us and there is activity on P1.7 (MSP TXD). See Figure 4.

Figure 4. FR2355 about 60s into starting mspdebug showing activity on MSP TXD line

Aaron Barrera: This *should* be 9600 baud. According to the output of mspdebug: there's a failure on 0x1e command and attempts to perform a mass erase but fails.

I've been poking around the mspdebug source code, and I believe this is an mspdebug problem.

I haven't found a fix yet, but I came across these BSL commands, and they seem wrong:

#define CMD_MASS_ERASE        0x18
#define CMD_ERASE_SEGMENT    0x16
#define CMD_TX_DATA        0x14
#define CMD_RX_DATA        0x12
#define CMD_TX_VERSION        0x1e
#define CMD_RX_PASSWORD        0x10

Could the above be old BSL commands?

These #defines should be:

#define CMD_MASS_ERASE        0x15
#define CMD_ERASE_SEGMENT    0x16
#define CMD_TX_DATA        0x18
#define CMD_RX_DATA        0x10
#define CMD_TX_VERSION        0x19
#define CMD_RX_PASSWORD        0x11

I'm still trying to figure out which commands are sent. What I suspect mspdebug does right now is something like the following:

1. Send BSL entry sequence (correct)
2. Delay 500ms before sending first command (correct)
3. mspdebug writes 0x80 header (correct?)
4. mspdebug waits for ACK from MSP (does MSP send an ACK immediately after the header?)
5. mspdebug tries items 3 & 4 two times before giving up (mspdebug calls this "fails to sync").
6. send TX version command
7. wait for reply and fails after no reply
8. mass erase at this address 0xFFFE with this length 0xA506
9. mspdebug tries to sync (items 3 and 4 of this list) and fails

Does this "syncing" need to happen? I'm defining "syncing" to be sending just the header 0x80 and waiting for an ACK.

Ideally, after writing the BSL entry sequence, I'd just erase the device and and transmit the new program data.

Hi Gary,

We will get you a response tomorrow by the end of the day, thank you for your patience.

No worries, I've been digging into this, and I think it's more of an mspdebug issue. I don't believe mspdebug has been updated to use the '5xx, 6xx' protocol as shown in the overview in Table 1 of SLAU550Z. I suspect that the rom-bsl driver of mspdebug uses the '1xx, 2xx, 4xx' protocol, which might explain why it works on my G2553 device and not any of my FRAM devices.

I'm attempting to modify the code in mspdebug (i.e. add an fram-bsl driver) to use the protocol as described in SLAU550Z. I'm hoping to have something working within the next few days.

Hi Gary, 

Thanks again for your patience. Let us know if you make any progress and please continue to follow the protocol described in SLAU550Z. We are currently building more knowledge into mspdebug and the FRAM custom BSLs. I will have a better reply beginning of next week in terms of what the mspdebug driver looks like and what devices the protocol uses.

Hi Gary,

Glad you got mspdebug up and running with the BSL protocol for the FRAM device! Thank you very much for taking the time to type this information out as it will be very helpful to share with the team and many others with similar issues.