Jump to content
Forum sending old emails Read more... ×
Peabody

Has anyone compiled BSL-Scripter from TI's source?

Recommended Posts

I'm on a mission from God to permit updating firmware on F5xx, F6xx, FRxx, etc. using TI's BSL-Scripter software and a generic USB-to-Serial adapter like the CP2102, which could be embedded in a project.  As things stand, Scripter requires either a "Rocket" programming device or an MSP-FET because it is those devices which actually generate the pattern on /Reset and TEST that invokes BSL on the target device.

I've written a short program that produces the special pattern on DTR and RTS of a CP2102, but when I run Scripter immediately thereafter, it brings both of those lines low and keeps them there.  Of course that puts the target device into /Reset, so not much is gonna get flashed that way.

I need to modify Scripter to add a MODE line or command line option called "INVOKE", which if present would cause Scripter to generate the required pattern on DTR and RTS itself, and leave them in the correct state. before doing whatever else it's going to do.  The source code is available, but it's way over my head.  It requires the Microsoft 2013 Visual C++ complier, and a bunch of third party stuff, including something called Boost.   I have none of that, and don't know how I would modify the code.  I did it for BSLDEMO, but that was plain C, with no third party stuff.

So I wondered if anyone here had ever gotten Scripter to compile from the TI source, and  if so, if he would like to compile a version for me (assuming I can figure out what to change).  The only code I can find that deals with DTR and RTS in the source is in TestReset.h, but I don't understand it.

 

Share this post


Link to post
Share on other sites
7 hours ago, nagaokanchi said:

Hello, I realize this is an old post but I have recently been required to get the BSL working on an MSP432 device. The BSL-Scripter was easy to compile once Boost was installed. I have uploaded everything required (except Boost) and instructions on what to do on GitHub: https://github.com/drcrane/bslscripter-windows 

I hope this information is useful.

Thank you very much for posting this.  I really appreciate it.  I'm surprised you remembered the original post.

I have downloaded the repo ZIP file, and will study it carefully.  But I suspect it will still be way over my head.  I've never actually used a "real" compiler before.  But I will do my best to figure it out.

Can you say what you needed to change to get Scripter to work with the MSP432?

 

Share this post


Link to post
Share on other sites

I have not changed the BSL-Scripter source code, only the support libraries (libusb-1.0.lib and boost specifically). The BSL source code is as supplied by TI so should work on all BSL supported devices. As I say I have this working with the MSP432 but since my application is non-standard I had to make some changes to the UART peripheral interface wrapper (see SLAU622G section 4.6 and 5 if you are interested) but these changes were limited to the firmware on the 432 and not the BSL-Scripter which works unmodified with the customized wrapper.

Share this post


Link to post
Share on other sites
Posted (edited)

At the risk of making you regret you did this, I need to ask if you can point me to anything that would explain what's going on in TestReset.h.  I know nothing about Boost, or really C++,  and the code there just doesn't make any sense.  I don't see where "initState" comes from.  It doesn't appear anywhere else in the source code, the libraries you included, or the Boost download I did.  Also, it appears to be circular logic, and writes before it reads - it all seems upside down.  But I've found that exact code elsewhere online as a standard way to do serial ports, but unfortunately without explanation.  I also don't see how the TestReset.h code ever gets executed. "TESTControl" and "RESETControl" don't appear in any other source file.

What I need to do is (1) stop Scripter from automatically bringing DTR and RTS low, and (2) have it instead generate the invoke pattern itself if a new MODE-line option is selected.  #2 I have already done in 😄

https://github.com/gbhug5a/CP2102-with-BSL-Scripter-for-MSP430

but I don't know about #1.  TestReset.h is the only source file dealing with DTR and RTS, but I can't change it until I understand it, and make sure changing it doesn't mess up other things.

Anything you or anyone can do to shed light on that code would be appreciated.

Edit:  I've done more searching, and have concluded that if TESTControl and RESETControl are not called from anywhere in the source code, then they are not being used.  But they could be.  By me.  It looks like these functions are the normal way to change the state of DTR and RTS.  So I should be able to call them with the appropriate argument.  Then I would only need to add the 10ms delays between state changes.

Also, if I'm generating the invoke sequence, it doesn't matter that the lines are brought low first (#1 above).  In any case, if TestRest.h isn't being used to do that, it's probably just the way Boost opens COM ports when FlowControl = None, and there's nothing I can do about it.

If that sounds right, then I'm going to concentrate on adding the "INVOKE" option to the MODE line (presumably the same way "PARITY" is done), and adding the invoke sequence.  And all I need to understand about TestReset.h is that the functions there work.

 

Edited by Peabody

Share this post


Link to post
Share on other sites

In your program you have used the EscapeCommFunction to alter the state of RTS and DTR lines. This is fine but seemingly not the way the BSL-Scripter was intending to do it.

After looking through the Boost Documentation I could not find a way to set the RTS and DTR lines on the serial port using boost::asio but it is possible to get the Windows handle and use it as you have in your C code. As an example I have added two new classes to TestReset.h which work correctly and in two different ways so you can see what I "think" the TI developers intended to do.

Have a look at https://github.com/drcrane/bslscripter-windows/commit/9772f73db3e6571576d64b99a90cb09d97735b54#diff-d06efd7c12c48b56d76f49a0a984d3d5 I am sure you will see what I have done and understand quickly.

Share this post


Link to post
Share on other sites

I agree that the code I used in my CP2102 repo is not right for this.  That was plain C, with no Boost involved.

But I don't understand what is wrong with TI's original TestReset.h code for Scripter.  It appears they DO use boost:asio to set DTR and RTS, and their code matches other examples I found online.  My changes to UartComm.cpp contain my new calls to the TestReset.h functions for switching DTR and RTS.  They have no connection to the CP2102 code.

What is still puzzling is why TI #included the functions in TestReset.h, but never used them.  Perhaps they used them in an older version.

Share this post


Link to post
Share on other sites

Thanks very much.  Your Set and Clr work quite well.  I've attached a scope picture showing what happens to the DTR and RTS lines.  There are two problems:

1.  Each sleep is supposd to be 10ms.  The first sleep is significantly less than that.  It may be necessary to add another 10ms sleep line right after that first one.  All the other sleeps are actually about 15ms.  I think that results from the default Windows tick time.  I think it's likely that the difference won't matter.

2.  The big problem is that after the last sleep ends, something is bringing DTR low - equivalent to rst.Set(), or resetting flow control to none, or something similar.  I don't know what is causing that, but it has to be fixed because DTR is connected to the /Reset pin, and nothing can be flashed if it goes back low and puts the processor into reset.

 

Scripter.jpg

Share this post


Link to post
Share on other sites

Your reply is really helpful, thank you!

I would expect that this first delay will vary depending on when the function is called. You are probably correct in that the default tick time is fairly coarse. To work around the problem I have changed the implementation to make use of the timeBeginPeriod function as in your C code. If 15ms is acceptable we could look into aligning the delays: That is to say perform the first delay before the change (the exact period would be unpredictable but as it is before any pin states are changed that should not matter) and then run through the sequence... I believe this would be better than using a platform specific sequence, we can try this once it works ;-).

This may be related to the SetCommState vs EscapeCommFunction calls, in the boost::asio source code these lines are present:

if (!::GetCommState(handle_service_.native_handle(impl), &dcb))
if (!::SetCommState(handle_service_.native_handle(impl), &dcb))

So if we change the implementation to the one I commented out in the code it should work!

I have made the code changes and updated the repo, please test it:

https://github.com/drcrane/bslscripter-windows/releases/tag/v0.0.2-6a4c737

Share this post


Link to post
Share on other sites
4 hours ago, nagaokanchi said:

Seems I need to learn more about boost::asio. Please see the latest release for binaries and changes to the code.

https://github.com/drcrane/bslscripter-windows/releases/tag/v0.0.3-6024887

I haven't looked at your latest version, but I tested the release build version 2, and it works!!!  The 15ms sleeps don't seem to matter.  Pics below.

So at this point we have several variations open related to sleep times and methods used to change DTR and RTS.  I would suggest that you just pick what options seem best to you and let me confirm one last time that they works, and we can publish.  🙂  One issue that comes to mind concerning which choices to make is that if one option might be usable in any future Linux or Mac version, that might be the best one.  The other consideration is that the fewer changes to TI's code, the more confidence others will have in the outcome.  So, for example, if this latest version leaves TI's original TestReset.h unchanged, that might be best even if it isn't very elegant.

I can't thank you enough for jumping into this.  I'm very pleased that this BSL option now exists.

Edit:  I just tested Release V3, and it works too.  So let's just go with that one.  What do you want to call it?  How about BSL-Scripter340B.exe?

Scripter Release2.jpg

ScreenCap - Release2.jpg

FTDI module - FR2311.jpg

Edited by Peabody

Share this post


Link to post
Share on other sites

I agree, making the smallest number of changes is the best and in this case most of the changes were due to the upgrade of the build system.

I will re-organize the repo so that the minimal changes to TI's software are apparent.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×