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

Bug #1258574 reported by Tom Szilagyi
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python-msp430-tools
New
Undecided
Unassigned

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.

Background:

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.

Results:

After fixing several bugs I was able to carry out the following
operations:
- 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
msp430.bsl5.uart.main()

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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.