I am testing a download to a msp430 bootstrap loader from a MSP430F518 over a serial interface. I toggle the reset lines correctly to get the MSP430 into BSL mode, and start sending BSL Syncs and commands. Although the documentation very clearly says the BSL UART protocol is 9600 baud, 8,N,1, the communication with the MSP430FE4272 does not work at 9600 baud. It seems to work great at 1200. I have verified the baud rates with a scope.
How can this be?
I do not know what MSP430F518 is. Could you confirm?
Some of the MSP430 members use what the first byte that the PC sends to it as its time-base. It assume that it is the byte 0x80 at 9600 8,N,2 or 9600 8,E,1. If you determined that it is 1200 instead, that means it is using a wrong time-base 8 times too slow. It will over erase and over write Flash for 8 times too long.
What did your PC program send after it invoke the BSL Entry Sequence? What byte value and at what rate?
Yerk. That is the MSP430F5418.
The BSL documentation for the MS430F4272 states unequivocally that it communicates at 9600 baud. It does not mention being able to do autosense, and it expects to do 8,E,1 (I wrote that wrong above, too, when I said 8,N,1).
The first thing the other microcontroller (the MSP430F5418) sends it is a sync byte 0x80. When it does this at 1200 baud it gets back a 0x90 and everyone is happy. When it does this at 9600 baud which I haven't done recently, either I get no response at all from the F4272 or I remember occasionally getting a fairly compressed 0x90 that was not recognized by the F5418.
Then I send an Erase Whole Flash command. This works at 1200, I get back a 0x90, but again no response at 9600.
My main memory of my troubles at 9600 baud is that I can't get past the SYNC exchange.
ROM based BSL assumes that the incoming BAUD is 9600. It uses the timing of the incoming sync byte as time-base under this assumption. If your F5418 uses 1200 BAUD, F4272 will assume that is how 9600 should look like and uses that as the wrong time-base. Thus it will respond with the wrong wrong (two wrongs) 9600 BAUD, which is exactly 1200 BAUD. The communication will work because two wrongs made it right. But the the timing of Flash etc. will be a factor of 8x too slow.
TI does not want to call this auto-sense to avoid misleading you to think you can use a BAUD other than 9600. But you seem to have done exactly TI was afraid of.
So what is your timebase on the sending MSP? It should have a high-speed crystal as timebase for the 9600Bd. If you use REFO isntead, then you have a big, big timing error on every bit, and the slave MSp doesn't know how to extract a proper baudrate from this.
On 32768Hz UART clock, each bit on 9600Bd is 3.41 clock cycles. That means, one bit is 3, the next is 4 cycles long, the baudrate changes between 10923 and 8192Bd for each bit. The BSL simply cannot work with this.
Using the 5418s FLL to stabilize the DCO to ~1MHz and using 1MHz/9600 = 104 as baudrate divider (no modulation!) greatly reduces this problem. While the baudrate still isn't 100% perfect (it is 9615Bd +- REFO tolerance +- DCO jitter +- FLL jitter) it is at least stable and in the right range. So the BSL can work with it and won't be too much apart from the optimum.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Okay, sure, but then why doesn't it respond properly when I use 9600 baud? Communications are perfect at 1200, very rarely successful at 9600. And I am getting my baud rate settings values from the Frequently Used Settings section of the F4518 manual, which I independently verified by doing the calculations myself.
The UART is using the DCOCLK, which is stabilized at 16.777MHz.
The UART ctrl registers are:
UCA0CTL0 = UCPEN | UCPAR; // parity is enabled and parity is even UCA0BR1 = 00; // See 26.3.13 Typical Baud Rates and Errors in User Guide UCA0BR0 = 0x6D; // INT((16777216/9600)/16) UCA0MCTL = 0x41; // UCO16=1,UCBRF0=4, UCBRS0=0
Johanna Johnstonwhy doesn't it respond properly when I use 9600 baud
For 1200Bd, the error is much smaller: 32768/1200 = 27.3, so the masters sending baudrate is 1213Bd or 1170Bd for each individual bit, 1200 in average. Which is close enough so that the MSP will be able to understand the answer whether it comes with 1213 or 1170Bd when 1200Bd average are expected. Worst case the data is 1/4 bit length off after one complete byte. On 9600Bd, the difference is >2 bits after one byte, which is unreadable.
One example: On older Word versions, teh spell checker tried to autopmatically detect the used language. And when I swrote a text that began with a few English words (because they are commonly use din Germany too), it thought I write an English letter and then complained about every single German word later on.Same happens for the 9600Bd communication based on 32768Hz clock. The inital sync is ambiguous (as it is no clean 9600Bd) and then the communication fails.
Johanna JohnstonThe UART is using the DCOCLK, which is stabilized at 16.777MHz.
You could try without UCOS16. I remember a pretty old thread where we discovered that under certain circumstances not using oversampling mode is the better choice if the sender isn't that precise.
Also, don't forget that DCOCLK, even if stabilized by FLL, isn't too precise. Even if the expected frequency is available through modulation, it will have a jitter (disappears over 32 clock cycles). but there is a chance that modulation alone cannot exactly reach teh desired frequency, so the FLL will even change modulation on every reference cycle. Causing a larger jitter on each adjustment cycle.
Still, it shouldn't be so much that it will cause 9600Bd communicaiton to fail.
Well, did you try to access the target MSP from PC? Did it work okay then? i fnot, maybe you have the unlucky situation that your MSP is faulty and maybe not fast enough to do the 9600Bd uart in software due to a too-low default DCO clock or any other unlucky coincidence. It's just a distant possibility, though.
Here is what I think. (1) The host (F5418) should use 9600 b/s 8-bit Even Parity. The BAUDRATE does not need to be very accurate. But the timing of its transmission needs to be stable and free of glitches.(2) To start BSL, the host should drive the target (FE4272) nRST and TCK pins according to the BSL Entry Sequence. The timing is not critical at all. But to be prudent, all the transitions should be at least 1 usec apart.(3) The first byte the host sends should be 0x80 (sync). The target may need some time to react to the BSL Entry Sequence. Hence after nRST is released, it is prudent that the host waits at least 500 usec before it sends that first byte. Make sure that the target BSL RX line is always driven high (inactive) when nothing is being transmitted (free of glitches). Thus it is prudent that the host set up its own UART and starts to drive the target BSL RX line high before it releases the target nRST. (4) If the target does not respond or responds incorrectly, the host could go back to step (2) and try again.
Please ignore the above post. It was totally wrong. If I could delete it I would.
Johanna JohnstonPlease ignore the above post. It was totally wrong. If I could delete it I would.
However, you can still edit your post and erase its content (perhaps leaving a short note that or why you did it)
Finally back on this project. Here are some measurements and observations. I spoke out my hat when I said the FE4272 BSL was not seeing the bytes coming from the F5418. It mostly does. When I send 3 0x80 (SYNC)s in a row, it ignores the latter 2. I don't know what this is about and it doesn't really matter to me. It always responds to the first one. But the F5418 misunderstands the ACK! I finally got a scope on there and wrote down measurements and made some calculations, and it looks to me like the FE4272's 9600 baud is really more like 9090, even though the F5418 is sending it a tidy 9600 baud.
The F5418 was configured to communicate at 9600 baud, lsb first, even parity, 8 bits.
The F5418 sent 0x80 (SYNC), and the Fe4272 responded with 0x90 (ACK).
The measurable part of 0x80 does not show the 0x1 of the 8, the parity bit, or the stop bit. Therefore, of the 11 total bits in the byte, only 8 show in a measurable way.
The measurable part of 0x90 does not show the stop bit. Therefore, of the 11 total bits in the byte, 10 show in a measurable way.
The measurable part of the 0x80 sent by the controller was 803usec long, repeatedly. Divided by 8 got me a bit length of 103.75 usec/bit.
The measurable part of the 0x80 response from the meter was 1.1ms long, repeatedly. Divided by 10 got me a bit length of 110 usec/bit.
9600 baud gives me 1/9600 = .000104 sec. = 104 usec per bit, which is very close to the rate at which the controller is sending data. Calculating backwards from the bit rate of the meter response gives me a baud rate closer to 9090 baud.
What is that all about?
Johanna Johnston... The measurable part of the 0x80 sent by the controller was 803usec long, repeatedly. Divided by 8 got me a bit length of 103.75 usec/bit ...
You seem to have a typo. 803/8=100.375 probably should be 830/8=103.75Assuming that is the case, I have to conclude that the BSL code in your FE4272 has a small flaw and causes a 6% error in timing. (I expect ~1% error.) What is its silicon revision? If it is possible, could you dump the contents of locations 0x0C00 to 0x0FFF and show them?
I have looked at the BSL code for other MSP430 chips. But I do not have a FE4272.
correct, that was a typo. 830usec was the measured value.
Looking at the BSL version with FET Pro430 flash programmer I see version 1.61, but that doesn't let me see memory below 0x1000.
The debugger says:
0C0E0C04 02204031 43C0430B C232F60A 0032C0F2 40B20000 01205A800040D032 005043C2 009840F2 C0F20051 00520080 0021D3D2 0022D3D20003C0F2 C3E20026 40B20022 012CA510 A50040B2 C03B0128 12B0003A43820E80 43090212 020A4036 12B04237 4CC60F56 53160000 23F98317020B4255 00129075 90752473 24600010 0E5212B0 020B4255 0018907590752430 24A4001E 00209075 B22B2416 90752411 24210016 001490759075249F 2417001A 001C9075 3C042438 0EE012B0 53213FC2 0EE612B012B03FBE 42D20EE0 0050020E 020F42D2 42D20051 02160210 12B03FB242100EE0 4216020E 4315020E 40363C07 40B2FFFE 0210A506 000C4035A50040B2 4292012C 01280210 000043B6 012CB392 831523FD 903623F327CEFFFE 02004037 FE00F036 42163C04 4217020E 43350210 2003967523FC8317 46823FBF 3FC00200 FFE04036 00204037 0F5612B0 2401967C8317D32B C22B23F9 0E5212B0 3FACD22B 020E4216 02104217 2431B22B0010D03B 0F5612B0 10009036 90362C06 2C090100 00004CC6 40B23C1E012CA500 A54040B2 B3160128 4CC22003 3C130214 02154CC2 FFFD9A86D32B2401 02019036 D23B2804 0010B03B C03B2402 421A0032 4A8602145316FFFF 23D48317 0E5212B0 12B03F75 83170F56 12B023FC 3F720E520FF040B2 40B2020E 02100010 008040B2 42D2020A 020C0210 021042D24382020D 43090212 020A4036 467C4227 0EEA12B0 23FB8317 020E421602104217 01009036 46B2280A 425C0214 12B00214 83170EEA 0215425C467C3C01 0EEA12B0 23EE8317 0212E3B2 0212425C 0EEA12B0 0213425C0EEA12B0 42183EF8 12B00212 4CC20F56 12B00212 4CC20F56 E33802132404B23B FFFE9A86 D32B2401 02129218 B32B2322 41302320 0020B3E2B3E227FD 23FD0020 022440B2 B3E20160 27FD0020 01704215 1105110545821105 11050202 02044582 001E80B2 42570204 80370216 1105000353171105 503523FD 4582A540 4235012A 022440B2 92920160 0202017083152FFC 430923F7 0090407C 407C3C02 43C200A0 ECC90207 E31902124255C31B 45550207 55000F00 2E2E2E0C 2E2E2E2E 34341A2E 0170429250B20172 0172000C B31B3C07 4382200B B3920162 27FD0162 0021C3D2114C3C0A E31B2BF6 01624382 0162B392 D3D227FD 52920021 01720202020753D2 000C90F0 23D1F2B7 43C24130 C31B0209 02094255 0F664555560C5500 56565656 36565656 B3E20076 23FD0020 01704292 5292017201720204 01624382 0162B392 B3E227FD 281E0020 3C1CD32B 3C1A104C01624382 0162B392 B3E227FD 28010020 B31BE31B D32B2401 0212ECC93C0AE319 01624382 0162B392 B3E227FD 2BE60020 E31B104C 0202529253D20172 3FC00209 01624382 0162B392 B3E227FD 2C010020 4130D32B40015242 00000000 61010000 36424501
I
The relevant fragment of BSL code for G2553 is as follow:0E7E B0F2 0020 0020 bit.b #0x20,&P1IN ; (a) RX must be high0E84 27FC jeq 0xE7E0E86 B0F2 0020 0020 bit.b #0x20,&P1IN ; (b) wait RX to go low0E8C 23FC jne 0xE860E8E 40B2 0224 0160 mov.w #0x224,&TA0CTL ; (c) start Timer0E94 B0F2 0020 0020 bit.b #0x20,&P1IN ; (d) wait RX to go high0E9A 27FC jeq 0xE940E9C 4215 0170 mov.w &TA0R,R5 ; (e) read the Timer count0EA0 1105 rra.w R5 ; (f) divide it by 80EA2 1105 rra.w R50EA4 1105 rra.w R50EA6 4582 0202 mov.w R5,&0x202 ; (g) save that in RAMWhere the leading edge of the 0x80 is detected by polling-loop (b) and the trailing edge is detected by polling-loop (d). The Timer Count between them is read by (e). BSL uses the default DCO and is about 1 MHz. I estimate that the error of (e) is about 8 counts. Out of about 830 this amounts to about 1%. So I do not understand why you got such big discrepancy.I normally use KichStart to examine everything inside the chips. It can disassemble the code too.