Launchpad Based MSP430 UART BSL interface (slaa535)

just to add some information. The basic idea of this application note is to provide a low-cost solution for the gap of UART BSL hardware interface which we haven't had since sometime. So i came to the idea by thinking what is the most known MSP430 hardware tools with UART interface, which is of course Launchpad (unfortunatelly i missed the point with the parity bit, ouch..).

At first, i thought about implementing the solution by store and forward solution instead of bit-banging the GPIO to bridge the UART data, however because currently all G2xx devices have only maximum 1 serial interface, i needed to implement another Timer_A based UART interface. After some tests, i found that the Launchpad somehow could not cope with the speed (even with 9600 baud) by using this kind of solution.  This will work if i would add some delay in sending every byte in the BSL Scripter code, however after discussing with the MSP430 tools team, they want to implement something which could work with the current available  BSL_Scripter solution without any modification, and therefore i saw only the only possibility is to use the bit banging mechanism.

I just tested another solution by using the MSP430G2553 with store and forward mechanism (with some delay addition in the BSL Scripter code) and it works also for the CC430 hardware UART BSL. The idea is to use Timer_A interface between PC and Launchpad (both working with 9600 baud and no parity), and USCI interface between Launchpad and MSP430 target (with 9600 baud, even parity). This should also work, but the BSL Scripter can not be used "as is" without any modification.

I am trying to discuss with the tools team whether it is possible to add the UART feature of 9600 baud with even parity into the Launchpad emulator firmware. However, this is of course not a short term solution. For short term solution, i would advise to use the G2553 which has USCI interface and use the modified BSL Scripter.

Hope everything is clear now.

Leo,

Thank you for the explanation. I have a few questions:

About the current BSL Scriptor in COM Port mode (as oppose to USB mode):

(a) After it wiggles RST and TEST/TCLK, it sends SYNC and waits for ACK. How long does it wait? If there is no ACK, I think it sends SYNC and waits for ACK again. How often does it re-try? For how many times before it gives up?

(b) When the Scriptor sends a command, I think there is a gap between the bytes. Is this true? Is there about 1 msec between the Stop-Bit and the next Start-Bit?

(c) With the exception of handling MSP430F54xx (none-A version), I think Scriptor always send bytes with even-parity. Is this true? Does it check parity of incoming bytes from MSP430? Are parity error ignored?

About the BSL code inside MSP430 or CC430 chips that use COM Port (not USB or RF):

(d) I think the BSL code can choose to check or ignore parity bit. This is independent of whether they use Timer-UART or hardware-UART. For example,I know most F1xx and F2xx BSL use Timer-UART and they do check parity. You cited two actual BSL code, one ignores parity, the other one rejects bytes with parity-error.  What about other F5xx and F6xx?

(e) What about FRAM chips and Wolverine?

I do not have a need of a BSL interface for myself. I asked these questions just out of curiosity.

Regards,

OCY

lhend said:

... I just tested another solution by using the MSP430G2553 with store and forward mechanism (with some delay addition in the BSL Scripter code) and it works also for the CC430 hardware UART BSL. The idea is to use Timer_A interface between PC and Launchpad (both working with 9600 baud and no parity), and USCI interface between Launchpad and MSP430 target (with 9600 baud, even parity). This should also work, but the BSL Scripter can not be used "as is" without any modification....

How is this another solution doing?

I just started my own version by using MSP430G2001 (or any MSP430G2xxx). It seems to work with the current BSL Scripter without any modification. However, it seems that the BSL Scripter has quite a few bugs and the old BSLDEMO2 does a much better job. I will need to do more tests to confirm my findings. I do not have all the various Targets to test. Are you interested in my G2001 version? Could you test it?

Hi OCY,

old_cow_yellow said:

How is this another solution doing?

The solution works quite well, however i haven't tested to read large chunk of data from the MSP430 target. But at least for the test, it works quite well.

old_cow_yellow said:

I just started my own version by using MSP430G2001 (or any MSP430G2xxx). It seems to work with the current BSL Scripter without any modification. 

How are you doing it? Have you tested to download/read out large chunk of data (for example downloading the Big_File.txt supplied in the SLAU319? The problem i was telling you is that the Launchpad is too slow for handling those kind of data. Would be interested of course to know how you design the Launchpad to bridge the data in this case.

old_cow_yellow said:

However, it seems that the BSL Scripter has quite a few bugs and the old BSLDEMO2 does a much better job. 

Which bug do you mean? The most common bug for the BSL Scripter is that it won't work with USB Virtual COM PORT which is greater than 9. Well other "bugs" i know from BSL Scripter is that for example when you try to download a txt file but the file doesn't exist, it will just crash.

old_cow_yellow said:

I do not have all the various Targets to test. Are you interested in my G2001 version? Could you test it?

Sure, but i won't be able to do it until the next two weeks. 

Leo,

I was busy with something else too and did not get back to you about my implementation of this BSL Bridge.

You said the Launchpad is too slow. But your code is using 1MHz and the Launchpad is capable of up to 16MHz. I set RSEL=13, DCO=3, and MOD=0 (~7MHz) and there is no need for hardware UART nor special version of PC software. I think it work fine.

I have tested this with MSP430F1232, F135, F149, F2417, F5419A, and FR5739. I do not have anything else to test with. Can you find some time to try it?

--OCY

Hi OCY,

yes i implemented this only with 1 MHz because it works already with 1 MHz. Does it mean that you only change the clock setting the SLAA535 code or do you have any other changes?

Leo,

No, I redesigned the entire thing. I think it works with any MSP430 member that has UART or Timer-UART BSL; but I cannot verify that.

This is a summary of what it does:

a) At power-up or SW1 generated reset, it drives Target nRST and TCK (if any) low, pulls up SW2, hold WDT, and wait a while for SW2 pull-up to work. It then waits for SW2 to be pushed. During this time, both green and red LEDs are off.

b) When SW2 is pushed, it drives Target nRST, TCK, and TEST to invoke BSL Entry Sequence. As a result, the green LED is turned on because it is on the same signal line as TCK.

c) If the Target recognized the BSL Entry Sequence, the red LED should also light up because it is on the same signal line as Target BSL TX.

d) It speeds up the DCO to ~7MHz with no modulation and wait for PC TXD or Target BSL TX.

e) It replicates PC-TXD and sends that to Target BSL-RX. But at the end of each byte, this replicate has the option to append an Even Parity Bit. It also replicates Target BSL-TX and sends that to PC_RXD.

f) The first byte from PC-TXD is always 0x80. This is true for any ROM-Based BSL or Flash-based BSL. This is used to calculate the BAUD divider for ~7MHz DCO to get 9600 b/s.

If you want, I can send you the entire code. It is in public domain.

--OCY

Just to give an update,

the SLAA535 has been updated http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=slaa535a&docCategoryId=1&familyId=342.

The new version has been tested on various MSP430 device families ranging from 1xx, 2xx, 4xx, and 5xx family devices. including the CC430. I want to thank OCY for his contribution for this update.

Hi,

I'm trying SLAA535 with this board. But the LPAD_BSL_INTERFACE project does not even compile. It shows a few errors during compilation:

#20 identifier "TIMERA0_VECTOR" is undefined main.c /launchpad_bsl line 470 C/C++ Problem

#20 identifier "TIMERA1_VECTOR" is undefined main.c /launchpad_bsl line 517 C/C++ Problem

#20 identifier "USI_VECTOR" is undefined main.c /launchpad_bsl line 591 C/C++ Problem

Can you please give me some hint on what may go wrong? Thanks.

BTW, I'm using CCS 5.2.1.

Hi,

i guess you are using the MSP430G2553 on the Launchpad?

If yes, you can use the source code which i posted here: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/209340/741073.aspx#741073

Hi,

Yes, I'm using MSP430G2553.

The code (3323.lpad_bsl_int_G2553.c) compiles now, but both LEDs blink, meaning the BSL invocation fails. Can you please advise where might go wrong? Thanks.

Hi,

since you are using a custom board, i would suggest to check for the connection. Have you connected the right pins of the MSP430F1611 on the custom board (RST, TCK, Data Transmit 13 - P1.1, Data Receive 22 - P2.2)?

You need to push the reset button on the launchpad to try reconnecting with the BSL again.

Hi,

You are right.

My connection is below:

MSP430G2553                  TelosB

VCC                                     U2.1 (i.e., PIN 1 at expansion U2)

GND (J6)                             U2.9

P1.6                                     U2.4 (UART0TX)

P1.7                                     U2.2 (UART0RX)

P1.4                                     U28.6

P1.0                                     U8.7 (i.e., pin 7 at JTAG)

But actually, BSLTX is pin UART1TX and BSLRX is pin UART1RX, both are only found in I/O buffer. Is there anyway I cannot connect to these two pins (BSLTX and BSLRX) in my board? They are not in expansion pins nor JTAG.

More information about my TelosB board is here. Thanks.

Leo,

The BSL entry sequence in slau319 does not always work. It depends on the current contents of Flash. One needs to include the RED part of what is shown below:

Hello All,

I saw mention of the BSL stuff and Wolverine.  I have a test harness based on the FTDI chipset - and I do have BSL Scripter working with that.  There is one important change needed to get it to work - I have posted about that previously.  

Wolverine will otherwise work by selecting the 5xx 'mode' and building a correct script file.

I am also working on the GUI based on the USB_BSL app - and should have that working soon - I may be able to make that public - I will have to check.

But, the good news I suppose is Wolverine works just like any of the other 5xx devices as far as the BSL Scripter is concerned.  I thought it may be necessary to force a wait state due to the FRAM - but looks like the internal BSL program in Wolverine must be accounting for that - or maybe it isn't needed.  I haven't looked yet at putting a custom BSL app onto Wolverine - but that should be possible - like the rest of the 5xx devices.

Regards,
johnw 

John,

I hope yours can turn on/off the power of the target. I found it the hard way. See my posting just before yours (dated Nov 07 2012 14:51 PM)

-- OCY

OCY,

Did you catch the part about using the FTDI harness - I have been using this setup for a while, works just fine.

I did just try it with Wolverine recently - and - it works just fine.

Regards,

johnw 

OCY,

Also - the UART BSL sequence can be entered at any time - does not have to be right after a power up.  To me that is one of the nice features of the UART BSL.

For the USB BSL - the target does have to be power cycled or at least you have to go through a power sequencer to kick off that state machine properly.   Maybe this is a point of confusion.

Since the BSL is a sort of hardware state machine, I don't see how the contents of any Flash at that point makes 
any difference.  The BSL signaling is all driven by hardware.   

I have worked on both USB and UART BSL systems, boards, harnesses, etc. - never has the content of Flash been an issue.  The two are orthogonal. 

If you have two outputs trying to drive one signal - that is a hardware problem to me.  I would not call that a Flash problem.  I would just keep reset driven until the problem went away - which it will if it is in Flash.

Regards,
johnw 

John,

I do not have FTDI harness nor the Wolverine. But I believe they would normally work.

However, if you load the target with a code that gets itself in trouble very quickly before the BSL has a chance, BSL cannot start. Thus I think it is very important to hold RST before you power up the target. See the RED part of my posting. This will prevent the existing code to kill the BSL attempt.

-- OCY

johnw said:

Also - the UART BSL sequence can be entered at any time - does not have to be right after a power up.

Comes under system design.

If someone wants to do that - and they also want BSL to work - then you will have to have a handler - once the NMI is asserted that can put the device into BSL mode - like checking an I/O in the handler and if it is asserted - hit the reset vector.

All of the 'exceptions' you guys are touting can be easily solved.  Expecting TI to solve all of your system engineering problems is not their job.  If someone has reconfigured their RST pin - then it is simple - you have to reset the target to put it into BSL.  If they don't anticipate this - shame on them.  If the system won't allow this due to poor attention to requirements specifications - then provide a JTAG header and forget BSL altogether.

If anyone is interested - I have Wolverine BSLing from a ::bsl_uart_gui adapted from the TI USB BSL GUI.

Regards,
johnw