BSL question on MSP430FR6972

Hi Blake,

To get started, I'd recommend connecting to the device through the pins of the BSL Connector. Note that if you plan on using the BSL Tool/Connector with an external supply, you'll need to remove R3 and add a 0 ohm resistor for R2 (per the instructions in the schematic for the target board). However, I'll assume that you're manually connecting to the pins in the BSL Connector for now. For powering the target board, I'd recommend using the J2 connector.

For the jumper settings, I have included some feedback below:

• J1 -> 1-2 shorted
  • Depends on how you're powering the device
  • 1-2 requires that power must be supplied via JTAG connector
  • 2-3 should be shorted for external power, assuming J2 is used here
• JP1 -> closed
  • ok
• JP2 -> closed
  • ok
• JP3 -> 2-3 (UART)
  • should be ok, but could be removed as an additional test if BSL continues to not work
• JP4 to JP8 -> 2-3 (4-wire JTAG mode)
  • should be ok, but could be removed as an additional test if BSL continues to not work
• JP9 -> closed
  • ok
• JP13 -> open
  • ok
  • should be open for BSL connector usage
• JP14 -> closed
  • should be open for BSL connector usage
• JP15 -> closed
  • should be open for BSL connector usage
• JP16 -> 2-3 shorted (UART)
  • ok
• JP17 and JP18 -> open
  • ok

Now, aside from the target board, I'm suspecting that the "Change Buad Rate" command is causing the problem (assuming it's the first command). In Section 3.1.1.2 on page 4 of the Bootloader User's Guide, it mentions that "baud rates over 9600 baud at initialization may result in communication problems". Although you may be specifying a baud rate of 9600, the command itself could be the culprit here. Could you try sending a different first command and see if you receive anything?

Let me know if these two recommendations don't help, and we can dig deeper here.

Regarding the "JTAG has control over the MSP430’s resources" phrase, this means that if you have an active debug session over JTAG, you won't be able to start the BSL uisng the BSL RESET vector. It depends on the state of the device and not the configuration of the pins themselves. Does this make sense?

Regards,

James

MSP Customer Applications

As a follow-up, could you describe the setup for the host interface? For the software, I'd suggest using the BSL Scripter and for the hardware, I'd suggest using the MSP-BSL (Rocket) or MSP-FET. Now, the BSL Scripter runs the UART communication without parity by default, so the parity would have to be set with the MODE command.

Regards,

James

MSP Customer Applications

Note to James:   We had not seen your two posts above when we drafted the following..  More to follow after we have digested your previous information..

Here is the latest update:

We tried using the new setup below where by only connecting the Host to the target board via the BSL serial lines TX and RX, TEST and RST signals while providing power to the target board externally.  Unfortunately, the MSP430FR6972 is still unresponsive and does not seem to start the bootloader after the entry sequence and then sending a command.

What is normally used to plug into the 10-pin “BSL connector” that is on the MSP-TS430PM64F Target board?  Is this a different debug pod or cable?

We’re getting close to running out of ideas…   We’re hoping that we can have this resolved before receiving the actual prototype boards next week.

Hi James... going to troubleshoot on site after lunch tomorrow.  He could be using MSP-FET on the 14 pin header, or his own custom programmer on the 10 pin... I'll see tomorrow:

The PC host interface is using what we call our “black box programmer” to interface to our Viewer application that is based on LabView engine.  The black box has a standard USB-to-serial (3V TTL) converter (using an FTDI chip) that connects to the PC running Windows 7.  The UART (COM) is setup for 9600,E, 8, 1 when sending the commands to MSP430.  However, we “think” the processor may not be entering BSL mode given that we never get a response no matter what is sent to the MSP430.

The RTS/DTR signals connect to the TICKLE and /RST lines, respectively.  The, the HOST_TX connects directly to the target board’s RXD signal and the HOST_RXD connects to the target boards TXD signal.  It’s pretty straight forward…

We can’t use this for production since we come through a standard mini-DIN serial interface that connects to the TX, RX, TEST and RST lines.  We’ve been doing this for years and not sure why this particular processor is not working…

Just to confirm…

Our setup is using the MSP-TS430PM64F socket target board w/ the MSP340FR6972 installed along with our “black box” serial converter device to talk to the host PC. (9600, N, E, 8, 1)  

The host connects directly to the BSL RX, BSL TX, TEST and /RST pins on the 10-pin BSL connector on the Target Board as described in previous emails with the board being powered externally as suggested below.  

The jumper settings are set according to below as well and have tried sending different commands (i.e. RX password) still with no success.  

I am planning to purchase the Rocket BSL hardware and try using the BSL Scripter tool just to see how the /RST and TEST lines behave with this setup.  I’m not sure what else about our setup might be causing the issue…  

(I really would not be happy to find that we need a 10us pulse on the TEST pin like the 5436A devices (SYS10 bug) on the previous system….which forced us to have to use another micro to generate the BSL sequence to the 5436A)  

Hi Blake,

Thanks for the update and for trying the recommendations. I'm setting up the BSL Scripter on my PC, but it looks like I need to install Visual Studio 2013 to actually build the executable first. I'll be working on this tomorrow. EDIT: I found the .exe in the 'bsl-scripter-windows.zip' folder, so no need to install Visual Studio unless you want to modify the BSL Scripter.

Their setup is straightforward and seems to be fine. However, I'm glad to see that they're purchasing the Rocket BSL tool and planning to use the BSL Scripter - this is a good step forward in figuring out if the issue is related to the host or the microcontroller. The MSP-FET is also supported by the BSL Scripter, but it isn't as straightforward as using the Rocket BSL tool.

Is this behavior consistent for more than one microcontroller? Have they confirmed that the NMI bit is not getting set in their code? If the RST/NMI pin is configured for NMI functionality, the BSL will not be started by the BSL RESET vector.

Let me know how your troubleshooting goes.

Regards,

James

MSP Customer Applications

HI James,

Thanks for the help...  I suspect there will be a moment of clarity where we find something obvious like:

1) Signals aren't actually being sent to the processor pins (jumpers)

2) NMI bit set (like you mention)

3) Part number is for i2c BSL (checking this morning).

4) Great idea on checking a second chip.  I ordered him 3 from Digikey so he doesn't have many.  I have another 10 in my trunk from TI. We'll try those.

5) VCC isn't connected right.

I'll be over there at 12:30 your time, so hopefully by this PM I'll have some insight.

Best Regards, Blake