[PATCH] Fix several bugs in msp430.bsl5.uart

Bug #1258574 reported by Tom Szilagyi
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

The bsl5.uart methods in HEAD (r.486) are broken. I tried to use
this module with a CC430F5137 device without any success.


I am right now developing a firmware upgrade solution to our
MSP430-based product (using the above device) using the BSL,
so that the device firmware is field upgradable with a single UART
connection and no special hardware (eg. FET430) is needed.


After fixing several bugs I was able to carry out the following
- unlock BSL
- get BSL version
- upload memory area to host
- erase specific segment
- mass erase
- program device
- change baudrate for faster programming (I used 57.6 kbaud)

The attached patch contains my fixes after which the above
operations - none of which previously worked - became usable.

Outline of fixes:

- CRC16 computation done only on BSL core command section, as
  defined in slau319g.pdf section 3.2.2 (both when generating CRC
  for sending and when verifying CRC of received data)
- When changing baudrate, don't expect core response after
  receiving ACK (0x00) from BSL, as per the spec
- Expect correct number of response bytes
- A more robust way of entering the BSL (start pulse pattern).
  The existing method sometimes worked, sometimes didn't. I found
  that adding a further pair of edges to TEST made this always work.
- Use correct data types (string of length 1 vs. char vs. byte)

Additional information:
- python 2.7.4
- linux 3.8.0-25-generic x86_64

Hardware setup:

I'm using a FTDI C232HD UART cable which has 3.3V pin headers;
active low for signals RTS, CTS, DTR, DSR, DCD, RI. I am
connecting this cable directly to the CC430F5137 device (thru pin
headers on our custom PCB) according to this mapping (wire colors
are according to the standard FTDI cable coloring):

    FTDI RXD (yellow) <-- CC430 UCA0TXD (P1.6)
    FTDI TXD (orange) --> CC430 UCA0RXD (P1.5)
    FTDI RTS (green) --> CC430 TEST/SBWTCK
    FTDI DTR (grey) --> CC430 _RST/NMI
    FTDI GND (black) <-> CC430 AVSS, VSS-EP

As shown above, RTS and DTR are used to drive TEST and RST (as
usual), but since TEST is acvite high and RST is active low, the
--invert-reset option must be used at all times.

Tags: bsl5 msp430 uart
Revision history for this message
Tom Szilagyi (9-tom-m) wrote :
Revision history for this message
Tom Szilagyi (9-tom-m) wrote :

Updated patch also fixes BSL_LOAD_PC operation.

Revision history for this message
Federico (81joe81) wrote :

I was experiencing the same problems (could not program a CC430F5137 device), and I can confirm that these patches solved them.

Thanks a lot!

Revision history for this message
Ashfixit (ash-ubuntuone) wrote :

As a follow on to this patch - there is no script for the module in /scripts it's trivial to gin it up but it would be nice to have
it for parity with the other tools:

so in scripts/msp430_bsl5.py should read:

#!/usr/bin/env python

import msp430.bsl5.uart

Revision history for this message
Manuel Fernandez (mfst) wrote :

I'm trying to test this with my cc430 board but after applying patch I'm consistently getting this error:

$ python -m msp430.bsl5.uart -e -r -p /dev/ttyACM0

An error occurred:
[Errno 22] Invalid argument
Cleaning up after error...

What's more, the hid programming for other boards stopped working as well :

python -m msp430.bsl5.hid -r -e -i ihex -P build/dinmote2/main.ihex.out
Download full BSL...

An error occurred:
'HIDBSL5Target' object has no attribute 'bsl_header'
Cleaning up after error...

I'm using Ubuntu12.04 64bit and python2.7.3

Without patch applied I get timeout errors whenever I use the msp430.bsl5.uart. A colleague has managed to make it work in Windows though. Any suggestions?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers