• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 1895 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 BSL via uart

Damen Knight
Prodigy 250 points

Other Parts Discussed in Thread: MSP430G2553, AM3352

Hey guys,

I am trying to work out a way to replace the firmware on my MSP430G2553 from the ARM on the device that it is connected to, running linux (an AM3352).

Obviously since this is an embedded application, it is a little funky :D

We've got BSL-TX on 1.1

BSL-RX on 1.5

BSL_CTS on 2.0

BSL_RTS on 1.4

1.1 and 1.5 are uart3, so presumably this should appear on my system as a uart3 device

so I'm trying to connect to mspdebug to /dev/ttyO3

using tilib, it fails with:

./mspdebug tilib -d /dev/ttyO3 --allow-fw-update
MSPDebug version 0.22 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2013 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.

MSP430_Initialize: /dev/ttyO3
FET firmware update is required.
Starting firmware update (this may take some time)...
Initializing bootloader...
Initializing bootloader...
Initializing bootloader...
tilib: MSP430_FET_FwUpdate: MSP-FET430UIF Firmware erased - Bootloader active (error = 56)
tilib: device initialization failed

I'm guessing that I'm just not even vaguely connecting properly, but this is a bit outside my normal area :D so any guidance or tips on how to proceed would be hugely appreciated

  • 0
    Guru 227245 points

    The standard UART BSL does not use RTS or CTS. However, it requires two I/O lines to toggle RST and TST for the BSL entry sequence. I always confuse which is which, but since the signals need to be two outputs of the ARM, only one of RTS and CTS is to be used (as the other one is an input). The other output is from the DTR/DSR pair.

     However, the error output looks suspicious. It reports that MSPDEBUG tries to access the MSP through a FET (JTAG) and tries a firmware update of the FET. And fails. It doesn’t look like MSPDEBUG tries a BSL update. Or rather, it tries a BSL update of the FET, not a firmware upload through BSL to the target MSP. You probably used the wrong switches in the commandline.

  • 0 in reply to Jens-Michael Gross
    Prodigy 250 points

    yeah I dont actually think tilib is the driver I really want to be using - I suspect I want flash-bsl.

    Unfortunately that one doesnt work any better ;)  Just times out IIRC.

    I suspect the issue is that our reset/test pins are non-standard, and so MSPDebug doesnt isnt properly putting the MSP into BSL mode - I just dont know how to tell it which pins it should be using.  I've looked through the source, but all of that appears to be abstracted away.

  • 0 in reply to Damen Knight
    Guru 227245 points

    Take a look at BSL users guide SLAU319g.pdf
    It will at least explain the MSP side of theBSL.

     BTW: what do you mean with ‘1.1 and 1.5 are UART3, so it should appear as uart3 device’?
    1.1 and 1.5 are just two timer pins that provide RX and TX functionality and are somehow connected to the ARM. (btw, does the ARM provide TTL level signals or RS232 signals?)

    On which UART they appear on linux depends on where you connected these two pins to the ARM. (well maybe that’s what you meant with ‘are UART3’)

  • 0 in reply to Jens-Michael Gross
    Prodigy 250 points

    what I mean was that we have those pins (on the MSP) mapped to pins that equate to uart3 on the ARM device.

    In any event, we got it working.  We needed to clone the mspdebug repository (rather than using one of the official releases) and use the (not officially released) rom-bsl library with it - along with writing our own script to put the MSP into BSL mode, since mspdebug doesnt call the correct pins for our use case.

**Attention** This is a public forum