MSP430F6736: MSP430F6xxx UART Bootloader via USB bridge IC

Thanks, this nearly works for me. I can get it to upload a program on the second attempt. I have to run the script, watch it fail, disconnect the reset pin then run it again so that it does not re-invoke the BSL. I noticed when the BSL is invoked the Tx line on the MSP430 is driven low for a moment and I wonder if this is causing communication problems.

I get the following interaction:

---------------------------------------------------------
BSL Scripter 3.4.0.1

PC software for BSL programming
2019-May-29 15:26:35
---------------------------------------------------------
Input file script is : C:/Users/rtaylor/Documents/MSP430 BSL Scripter/BSL-Scripter-v3.4.1/test/BSL.txt
MODE MSP430F6XX INVOKE UART 9600 PARITY COM9
VERBOSE
Verbose mode is now on!
DELAY 1000
Delay 1000 ms
TX_BSL_VERSION
[80] [01] [00] [19] [e8] [62]
<00> <80> <02>

DELAY 500
Delay 500 ms
RX_PASSWORD
[80] [21] [00] [11] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff]
[ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff]
[ff] [ff] [ff] [ff] [9e] [e6]
<3b> <04> <e4>

DELAY 2000
Delay 2000 ms
RX_DATA_BLOCK BSL_Test2.txt
Read Txt File : C:\Users\rtaylor\Documents\MSP430 BSL Scripter\BSL-Scripter-v3.4.1\test\BSL_Test2.txt
[80] [20] [00] [10] [00] [40] [00] [81] [00] [00] [3c] [b1] [13] [44] [00] [0c]
[43] [b1] [13] [00] [00] [1c] [43] [b1] [13] [3e] [00] [32] [d0] [10] [00] [fd]
[3f] [03] [43] [3c] [0a]
<3b>
[ACK_ERROR_MESSAGE]Unknown ACK value!
[80] [7c] [00] [10] [d0] [ff] [00] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [00] [40] [b1] [00] [04] [00] [b2] [40] [80] [5a] [5c]
[01] [d2] [d3] [04] [02] [d2] [e3] [02] [02] [80] [18] [f1] [40] [a0] [86] [00]
[00] [81] [93] [02] [00] [03] [20] [81] [93] [00] [00] [f4] [27] [91] [83] [00]
[00] [81] [73] [02] [00] [81] [93] [02] [00] [f9] [23] [81] [93] [00] [00] [ea]
[27] [f5] [3f] [03] [43] [03] [43] [ff] [3f] [03] [43] [1c] [43] [10] [01] [4b]
[25]
<80> <02> <00> <3b> <05> <c5> <94>
[ERROR_MESSAGE]BSL Password is error!
Time elapsed of writing 148 bytes : 0.01895 seconds
Speed of writing data :7.629(kB/s)

After this I disconnect the reset signal and get this successful interaction:

---------------------------------------------------------
BSL Scripter 3.4.0.1

PC software for BSL programming
2019-May-29 15:26:45
---------------------------------------------------------
Input file script is : C:/Users/rtaylor/Documents/MSP430 BSL Scripter/BSL-Scripter-v3.4.1/test/BSL.txt
MODE MSP430F6XX INVOKE UART 9600 PARITY COM9
VERBOSE
Verbose mode is now on!
DELAY 1000
Delay 1000 ms
TX_BSL_VERSION
[80] [01] [00] [19] [e8] [62]
<80> <02> <00> <3b> <04> <e4> <84>
[ERROR_MESSAGE]BSL is locked!
DELAY 500
Delay 500 ms
RX_PASSWORD
[80] [21] [00] [11] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff]
[ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff]
[ff] [ff] [ff] [ff] [9e] [e6]
<80> <02> <00> <3b> <00> <60> <c4>
BSL Password is correct!
DELAY 2000
Delay 2000 ms
RX_DATA_BLOCK BSL_Test2.txt
Read Txt File : C:\Users\rtaylor\Documents\MSP430 BSL Scripter\BSL-Scripter-v3.4.1\test\BSL_Test2.txt
[80] [20] [00] [10] [00] [40] [00] [81] [00] [00] [3c] [b1] [13] [44] [00] [0c]
[43] [b1] [13] [00] [00] [1c] [43] [b1] [13] [3e] [00] [32] [d0] [10] [00] [fd]
[3f] [03] [43] [3c] [0a]
<80> <02> <00> <3b> <00> <60> <c4>
[80] [7c] [00] [10] [d0] [ff] [00] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14] [40] [14]
[40] [14] [40] [14] [40] [00] [40] [b1] [00] [04] [00] [b2] [40] [80] [5a] [5c]
[01] [d2] [d3] [04] [02] [d2] [e3] [02] [02] [80] [18] [f1] [40] [a0] [86] [00]
[00] [81] [93] [02] [00] [03] [20] [81] [93] [00] [00] [f4] [27] [91] [83] [00]
[00] [81] [73] [02] [00] [81] [93] [02] [00] [f9] [23] [81] [93] [00] [00] [ea]
[27] [f5] [3f] [03] [43] [03] [43] [ff] [3f] [03] [43] [1c] [43] [10] [01] [4b]
[25]
<80> <02> <00> <3b> <00> <60> <c4>
Time elapsed of writing 148 bytes : 0.2457 seconds
Speed of writing data :0.5883(kB/s)

Here is a timeline of the interactions

Robin,

Thank you for sharing details regarding your issues with using this third party BSL Scripter. Since this is not script written by TI I cannot speak to its performance but you can reach out to the community where you got the script from to see if they can provide insight into issues you are running into.

Information on proper BSL invocation for your device can be found on the MSP430 Flash Device BSL User's Guide on the MSPBSL landing page.

Best regards,

Matt

Hi Robin,

I'm glad to hear that you were able to find a HW hack to workaround the issues you were running into with the third party BSL scripter.

As for the low level logic requirements for a successful bootloader communication sequence, that is not something I have a deep understanding of because we provide HW and SW to perform the BSL sequence automatically (i.e. the MSP-FET & MSPBSL Rocket).

You are by all means more than welcome to continue working with the third party SW to use the PC and a virtual COM port to program the device through BSL but support would have to come from them.

Information regarding all of the methods of BSL programming that TI supports can be found in the MSPBSL Landing Page ( http://www.ti.com/tool/MSPBSL ).

Best regards,

Matt

Robin, I apologize for not replying earlier.  I just didn't see your post about the TX line problem.  I would very much like to know more about this because I have not seen anything like that with the FR part I tested with the revised Scripter.  Can you explain when the TX line goes low, and your change to the modified Scripter to fix it?  I wonder if the TX problem is family-specific.

I'm not able to recompile Scripter, and I'm not sure drcrane is reachable anymore.  Would you be willing to share your new source and new executable on Github as drcrane did?

Edit:

Ok, I think I understand now about the TX line.  You're saying that the processor's TX line is being brought low by BSL right after /Reset goes back high.  This would be the CP2102's RX pin.  There have been other posts here that described similar issues with the TX line going low at that point.  I don't think there was ever any resolution.  But this raises the question of whether the same problem would exist even using an MSP-FET or Rocket with Scripter.  If the problem is in the BSL code, there may not be much you can do about that side of things, but it may be that TI needs another modification to Scripter to cause it to ignore any such bad behavior on TX.  So far as I know, after UART hardware invocation, it is Scripter that sends the first tranmission.  So in theory it should ignore anything coming in before it does that.

In any case, I'll repeat my request that you make your work avialable via Github, including the .exe.  If I understand correctly, your changes would replace line 166 of UartComm.cpp.  The only question I have about your fix is whether closing and reopening the port would change the state of DTR or RTS, which we don't want to happen.  But your success indicates that that doesn't happen.

Hi George,

You raise a good point about closing the serial port. I guess it leaves DTR vulnerable to whatever UART IC is being used at the time to determine the state of DTR. I have changed it to instead wait half a second, then flush the serial buffer. It should only attempt to read bytes that are already in the buffer so hopefully won't affect micro-controllers that don't send junk characters. I have never seen "boost" before (I already hate it) so I can't be certain that this will work for everyone. It is concerning though that a single junk char can kill the unmodified program. For reference the Tx asserting manifests as 1 byte in the serial buffer.

As for sharing my copy of the project, I am happy to do it, just it seems very unstable. I can't use VS community so I have used VS express 2013 to get it into a state where VS express 2017 would recognise it and then successfully build it. Overnight my PC decided to make 2013 my default so the next day it opened in 2013 by accident at which point 2017 no longer recognised it. I had to delete the .vs folder to re-target to 2017 at which point it works again. I don't know much about visual studio so it was almost entirely luck that made it build. So far the exe works every time on my MSP430F6736 with CP2102. I have no other micro-controllers to test it on though.

So having said that if you still want this project I have never uploaded publicly to GitHub before. Am I supposed to add it to the existing project or do I upload to a completely new one? The image below contains all the code I've written so it's not a huge change if someone wants to add it to their 2017 community project.

if (modeParams->enInvoke) {
		PLATFORM_DELAY(15);

		port.set_option(RESETControl(1));
		port.set_option(TESTControl(0));
		PLATFORM_DELAY(15);

		port.set_option(TESTControl(1));
		PLATFORM_DELAY(15);

		port.set_option(TESTControl(0));
		PLATFORM_DELAY(15);

		port.set_option(TESTControl(1));
		PLATFORM_DELAY(15);

		port.set_option(RESETControl(0));
		PLATFORM_DELAY(15);

		port.set_option(TESTControl(0));
		//PLATFORM_DELAY(15); // Original delay to end the sequence
		
		// From here we flush the serial buffer to discard junk characters received between the microcontroller resetting and being stable in bootloader mode
		// For example MSP430F6736 pulls its Tx line low which this program interprets as a character. If we read more characters than are in the buffer then the rest of this
		// program falls over

		int bytesAvailable = 0; // Number of bytes in the buffer
		COMSTAT COMStatus;		// COM port status object containing buffer info
		char junkByte; // Sacrificial byte to store junk characters to
		PLATFORM_DELAY(500); // Wait for the microcontroller to settle into its bootloader
		
		int i = 0;
		for(i=0;i<100;i++) // Timeout after 100 characters just incase
		{
			if (0 != ::ClearCommError(port.lowest_layer().native_handle(),
				NULL, &COMStatus))
			{
				bytesAvailable = COMStatus.cbInQue; // Check for bytes in the buffer
			}
			else
			{
				std::cout << "Error checking serial port buffer\n";
			}
			
			if (bytesAvailable <= 0) // If there are no bytes in the buffer then we can move on
			{
				break;
			}
			async_read(port, boost::asio::buffer((void*)&junkByte, 1), bind(&UartComm::onRead, this, boost::asio::placeholders::error,
				boost::asio::placeholders::bytes_transferred)); // Start a non-blocking read to junkByte of 1 byte (first and second arguments of asio::buffer)
			PLATFORM_DELAY(5); // Give it 5ms to finish
		}
		
	}

Thanks very much, Robin.  If you haven't done Github before, I'm not gonna ask you to go to the trouble to set that up just for this.  Let me try to contact drcrane and see if he is still set up to compile.  If he can, I think it would be better because as I understand it he's only using the VS 2017 stuff.  Then he could just add your version to the Releases (with full credit to you).  Meanwhile, it would be helpful if you could post your changes here using the "Insert Code" icon "</>" above.  Edit:  I found an online OCR  utility that translated your code image to regular text, so you don't need to post it again.  I'll send the revised UartComm.cpp to drcrane.

I understand how TX going low could confuse Scripter.  That going low is a UART Start bit, which is going to end up adding a character to the input buffer.  If Scripter doesn't ignore it, it may be treated as the ACK to Scripter's first packet, and is almost certainly invalid.  So what you have done should probably have been there in the first place.   But I do think this TX thing may be family related.  I didn't see anything similar on the FR2311 I tested with drcrane's version.

Anyway, I'm glad you got it working.

Thanks very much.  I've sent you private mail here with suggestions for a few changes to clarify versioning.  But I've tested your new exe with my FR2311 setup, and it works fine.  So as far as I'm concerned, yours is now the go-to version for anyone who wants to use a generic USB-to-serial adapter for UART BSL for the parts supported by Scripter.  I really appreciate your efforts on this project.

I made some changes to the code to flush the buffer rather than read and then discard bytes.

github.com/.../bslscripter-vs2017

Feedback and PRs are welcome!

Benjamin Green said:

I made some changes to the code to flush the buffer rather than read and then discard bytes.

github.com/.../bslscripter-vs2017

Feedback and PRs are welcome!

A post from drcrane!!!  Well that's great.   But we need Robin to test your version with his F6736.  Then we'll have two versions of the junk byte fix.  Thanks very much for the new version, Benjamin.  Now if we could just get TI to get onboard....

I couldn't see an .exe in drcrane's repository so I have just assumed that only UartComm.cpp was changed. I put that file in my project and it programs my MSP430F6736 correctly. I will mark drcrane's post as the final solution if you put your .exe in there. But having said that I will still keep my repository up as well as mine is for VS express so there is less licensing problems I believe? Even though debug mode has a bug in it.

drcrane's .exe is under the "releases" tab at the top of his repo.  Here's the direct link:

https://github.com/drcrane/bslscripter-vs2017/releases

He also changed Version.h.  This makes the version displayed by Scripter something other than the last TI version.

I think it's fine to have both repositories up.  But just so we will all know for sure, it would be helpful if you would test drcrane's .exe with your F6736.   Then we will know that both .exe's fix this problem even though they were compiled differently.

I really appreciate your raising this issue, and fixing it.  I suspect the F6736 isn't the only part that behaves this way.  Now if we could just get TI to see the light.

Hi Benjamin,

Ah ok sorry I did not know about the "releases" section. If I do any more on this I may switch to community as it looks like the licencing is ok on that. The .exe works on my MSP430F6736 so I shall mark your latest response as the solution as it points stupid people like myself and those who are not interested in the source code directly to the .exe

Thanks for all the help.