MSP430G2553 BSL Programming

Hey Kyle,

I think you have the TX and RX lines crossed. The BSL on the G2553 is UART, which means a TX line on one side should go to the RX line on the other. You have both TXs (from the BSL Rocket and the 430) connected, and both RXs connected. Switch BSL pin 1 (Rocket TX) to MSP P1.5 (MSP BSL RX) and BSL pin 3 (Roxket RX) to MSP P1.1 (MSP BSL TX).

See if that solves your problem.

Mike

Hey Mike,

I switched the TX and RX lines but it didn't seem to work. Also, there doesn't seem to be any response characters with the lines switched which makes me think I had the lines correct the first time.

I have the MSP430G2553 chip placed in the socket for the MSP-EXP430G2 launchpad for easy connections. Should I use a breadboard instead? I don't have any of the bridge jumpers connected so I don't think it matters but I thought I'd ask anyway.

Thanks,
Kyle

Also, I made a clerical error in the first post, RST is tied to pin 4 of the BSL-Rocket and TEST is tied to pin 7.

Kyle,

I apologize for missing this in my first replay, but the BSL Scripter does not support G2xx devices.  Please use the BSLDEMO2 application from this page as it supports the G2553.

Mike

Thanks to both of you, I will try the BSLdemo tonight and respond on my findings.

Just for my own knowledge, I assumed 5xx stands for MSP430x5xx which would mean the G2553 series fits in that category. Or at least, that's what the Wiki describes it as: en.wikipedia.org/.../TI_MSP430. Am I incorrect?

I am attempting to get the BSLdemo to run but it gives the error:

ERROR: Synchronization failed!

Device with boot loader connected?

I am using the stock batch script that came with the demo:

@echo off

rem ---- initialize environment variables -----------------------------

setlocal

set workdir=%CD%

set HANDLER="%workdir%\bsldemo2.exe"

set BSL="%workdir%\bsl_150.txt"

set BSL130="%workdir%\BL_130V.txt"

set BSL150="%workdir%\BL_150S_14x.txt"

set TXT="%workdir%\test.txt"

set ComPort=COM9  

goto test1

:test1

echo --- test F413 (V1.30), F123 (V1.40), both 1 mass erase cycle ----

echo.

%HANDLER% -c%ComPort% -m1 +epvw  %TXT%

goto end

:test2

%HANDLER% -c%ComPort% +pvrw     %TXT%

%HANDLER% -c%ComPort% -w        %TXT%

%HANDLER% -c%ComPort% -s2 -w    %TXT%

%HANDLER% -c%ComPort% -w +vr  -pint_vect.txt %TXT%

goto end

rem ---- clear environment variables ---------------------------------

:end

pause

set HANDLER=

set BSL=

set BSL130=

set BSL150=

set TXT=

set ComPort=

Any ideas?

The first 'x' in MSP430x5xx refers to a letter, typically an 'F' in this case.  So a part number in this family would be MSP430F5529.  The number before the last 'x's is the family of devices, which would be all devices that start with the same number (a '5' in this case).  The "xx" after the '5' just refers to the specific part number in the family, and does not have to be only two digits.  This is why the MSP430F5529 is considered part of the MSP430x5xx family.  A lot of times, you will see
"5xx" or "F5xx" for short when referring to a family, which makes it easier to see that families are grouped by the first number in the specific part number.

For you error with the BSLDEMO2, double check your RX and TX connections as I discussed earlier.  If there is no BSL synchronization, it likely means either the device was not put into BSL mode (using entry sequence on TEST and RESET) or the serial data was not received by the device.  If you have an LSA or oscilloscope, you can use this to monitor your serial lines to make sure the correct data is sent.

Mike

I probed the TEST and RESET lines with a logic analyzer and they're both static. RESET is held high and TEST is held low. It doesn't seem that the program is making contact with the BSLRocket.