Has anybody tried the scheme described in TI Application Note Launchpad-Based MSP430 UART BSL Interface? See slaa535.pdf and slaa535.zip or:
http://focus.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=slaa535&docCategoryId=1&familyId=342
I have some serious doubt about this scheme.
Launchpad has an on-board emulator with USB interface that supports an Application UART (Virtual COM PORT) to communicate with the PC. The said Application Note tries to use this VCP as the interface to do BSL for another target such as the MSP430F5438A. But as far as I know, the LaunchPad Application UART does not support parity and the MSP430F5438A BSL requires even parity. So, how is that going to work?
Hi OCY,
nice catch there. I wrote the app note, and tested it on the F5438A which has Timer_A UART, and it should work. I also just realized that the Launchpad UART does not support the parity bit as required by the BSL specs. I have been also struggling to make it work on the CC430 which has the hardware USCI UART, and after a quick investigation, here are my first suggestion:
- the app note will only work with 5xx/6xx devices which have Timer_A UART (e.g. the F5438A). The reason of this is because in the BSL PI module using the Timer_A UART, the UART frame will not be rejected if the parity is not correct (or even does not exist). Take a look at the receiveByte() function in BSL430_PI_TA.c (you can download this on SLAA450 App note):
char receiveByte(){ int bitCount = 9; // Load Bit counter int dataByte = 0; TZNCCTL_RX = SCS + OUTMOD0 + CM1 + CAP; // Sync, Neg Edge, Cap while( !(TZNCCTL_RX & CCIFG) ); // wait for first char TZNCCTL_RX &= ~ (CAP+CCIFG); // Switch from capture to compare mode, turn off interrupt TZNCCR_RX += BitTime_5; while( bitCount > 0 ) { TZNCCR_RX += BitTime; TZNCCTL_RX &= ~CCIFG; while( !(TZNCCTL_RX & CCIFG) ); // time out one char dataByte = dataByte >> 1; if (TZNCCTL_RX & SCCI) // Get bit waiting in receive latch { dataByte |= 0x100; } bitCount --; } return (dataByte&0xFF);}
As you can see above, no matter what happen, the function will always return the received byte without really checking the parity.
- This is of course different for the hardware USCI UART BSL like the one in CC430 devices. The reason is that the frame will be rejected by the USCI hardware if the parity is not correct or does not exist:
char receiveByte(){ while( !(UCA0IFG & UCRXIFG)); // wait for RX flag return UCA0RXBUF;}
As can be seen above, the receiveByte() function in this case just waits until the UCRXIFG set by the hardware. This of course will not happen as long as the parity is not the correct one.
This is basically my pre-assumption, and i will try to investigate further. However as mentioned, it should work with the F543xA devices with the Timer_A UART BSL.
UPDATE: i have talked to the tools team, and they confirmed that this is the reason why the app note works on the device with Timer_A based UART BSL but not on the hardware UART BSL.
Hope this helps.
Regards,
Leo Hendrawan
- Now that my signature has caught your attention, please click the "Verify Answer" button if this post answers your question. Thanks! -
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.
OCY
old_cow_yellow (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?
I think you have mistaken between the Flash based BSL (on 5xx/6xx devices, works with BSL Scripter) and the ROM based BSL (older 1xx/2xx/4xx devices, work with deprecated BSL DEMO). The protocol is completely different between the two BSL types, and each of them is described in SLAU319 chapter 2 and 3. In this case, i think you are talking about the ROM based BSL, and the software tools for this is the BSL DEMO (please refer to this wiki page: http://processors.wiki.ti.com/index.php/BSL_(MSP430)#BSL_Tools). I am not really familiar with the BSL DEMO software, but the source code should be available also in the SLAU319 associated file.
old_cow_yellow (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?
Well, i am not an expert in Windows programming, but according to the BSL Scripter sources (which you can also download with the associated files of SLAU319), the writeByte() function does not contain any delay mechanism (i added delay however in the case of using my custom launchpad based solution with G2553). The transmission of series of bytes should be quite fast, i believe. Regarding the 1 ms delay, i am not sure about this since i have never measured this myself. If you want to know how the BSL Scripter works, i would suggest to download Microsoft Visual Studio C++ 2010 express edition (it's free), and then open the project file which i created a while ago here:
http://processors.wiki.ti.com/images/b/b0/BSL_Scripter_VC%2B%2B.zip
old_cow_yellow (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?
Well, again i am not an expert in Windows COM PORT programming, but looking at the source code of BSL Scripter, especially BSL_IO_UART.c, if the target device is not the F543x non-A version, the initializeCommPort() function will initialize the COM PORT file with even parity. On the other hand, the readByte() function will just read out a byte from the COM PORT file. I am not 100% sure however if the COM PORT driver on Windows will check the parity according to the one which is set, but i think it should do.
old_cow_yellow (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?
The code i cited above is basically taken from the SLAA450, the hardware UART BSL is taken from the CC430 one, while the timer UART is taken from the F5438A code. I am not sure about the older 1xx and 2xx code, since it has never been released publicly as the one for the 5xx/6xx ones.
old_cow_yellow (e) What about FRAM chips and Wolverine?
I am also not 100% sure about FRAM chips and Wolverine, since actually my privilege to the internal documentation is not so different as yours :) (considering i am just an application engineer whose main job is to give support to customers). However if i am not mistaken, in terms of protocol the BSL on FRAM devices should be considered similar with the Flash based BSL on 5xx/6xx devices altough on the FRAM devices the BSL resides in ROM (so unfortunatelly, no custom BSL possible).
Hope this clears things a bit.
lhend ... 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?
old_cow_yellow 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 I just started my own version by using MSP430G2001 (or any MSP430G2xxx). It seems to work with the current BSL Scripter without any modification.
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 However, it seems that the BSL Scripter has quite a few bugs and the old BSLDEMO2 does a much better job.
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 I do not have all the various Targets to test. Are you interested in my G2001 version? Could you test it?
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.
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
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.
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
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.
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.
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.