Need help understanding code segment

[Peabody]

I've written and compiled some very simple C programs, but never C++, and
never anything this complicated and obscure. The code below is extracted
from the TestReset.h source code file for Texas Instrument's BSL-Scripter.exe
program that's used to do UART BSL flashing of newer MSP430 microcontrollers.

Scripter is designed to be used with specialized hardware interfaces such as
the "Rocket" and MSP-FET, both of which generate the special BSL invocation
pattern on DTR and RTS. For reasons that are not clear, Scripter brings both
lines low when it runs. I would like to at least get it to leave DTR high,
or if possible actually generate the pattern itself so a generic USB-to-
Serial adapter can be used as the hardware interface.

Using a program called Agent Ransack, I searched all the source code files
for occurrences pof any of the relevant labels that involve the DTR and RTS
lines, and found that only TestReset.h contained any of them. Here's the
relevant code section for RTS, which would be connected to the TEST pin of
the MCU:

#pragma once

#include "stdafx.h"

# define MSPBSL_ON_WIN
# define BOOST_ASIO_OPTION_STORAGE DCB

class TESTControl
{
private:

uint16_t state;

public:
TESTControl(uint16_t initState)
{
state = initState;
}; // constructor

boost::system::error_code store(BOOST_ASIO_OPTION_STORAGE& storage,
boost::system::error_code& error) const
{

if (state)
{
storage.fRtsControl = RTS_CONTROL_DISABLE;
}
else
{
storage.fRtsControl = RTS_CONTROL_ENABLE;
}
return error;
}; // store

boost::system::error_code load(BOOST_ASIO_OPTION_STORAGE& storage,
boost::system::error_code& error)
{

if (storage.fRtsControl == RTS_CONTROL_ENABLE)
{
state = 0;
}
else
{
state = 1;
}

return error;
};
};


I don't know anything about BOOST. It appears that something called
"initState" is key to what's going on here, but I don't find that in any
other source code file, or any occurrence of "TESTControl" either.

Can someone explain what's going on here? Scripter does bring RTS low, which
I believe is ENABLED, so I think that means initState is zero. But I don't
know where that comes from. Also, I don't know what calls all this stuff.

Any clarifications will be appreciated.

[Louis Krupp]

I haven't got a clue, but you might want to look at these:

https://www.boost.org/doc/libs/1_69_0/boost/asio/serial_port_base.hpp

https://docs.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-_dcb

You might want to search the code for "fDtrControl".

Louis

[Paavo Helde]

This code just saves and reads a single integer, it does not do anything
substantial.

'initState' is the name of a local parameter, it's natural it does not
show up elsewhere.

If TESTControl doesn't either, then it's possible it is just some mockup
class used only for testing purposes and is not a part of the real program.

[David Brown]

On 15/03/2019 00:15, Peabody wrote:
> I've written and compiled some very simple C programs, but never C++, and
> never anything this complicated and obscure. The code below is extracted
> from the TestReset.h source code file for Texas Instrument's BSL-Scripter.exe
> program that's used to do UART BSL flashing of newer MSP430 microcontrollers.
>
> Scripter is designed to be used with specialized hardware interfaces such as
> the "Rocket" and MSP-FET, both of which generate the special BSL invocation
> pattern on DTR and RTS. For reasons that are not clear, Scripter brings both
> lines low when it runs. I would like to at least get it to leave DTR high,
> or if possible actually generate the pattern itself so a generic USB-to-
> Serial adapter can be used as the hardware interface.
>

Let's take a step back, and ask what you are actually trying to achieve.
If you are trying to program msp430 microcontrollers using the BSL,
then fiddling with this C++ code when you don't know any C++ is almost
certainly the most difficult way to do it. There are several existing
solutions for working with the BSL - in particular, there are libraries
and programs in Python for the job. If you don't know Python, and you
don't know C++, then you'll get further faster by starting with the
Python code than with the C++ code.

[Peabody]

David Brown says...

> Let's take a step back, and ask what you are actually
> trying to achieve. If you are trying to program msp430
> microcontrollers using the BSL, then fiddling with this
> C++ code when you don't know any C++ is almost certainly
> the most difficult way to do it. There are several
> existing solutions for working with the BSL - in
> particular, there are libraries and programs in Python
> for the job. If you don't know Python, and you don't
> know C++, then you'll get further faster by starting
> with the Python code than with the C++ code.

That's a fair point, and I may be approaching this wrong.
But the idea is to have a way to flash firmware updates in
the field, so that people who don't know anything about
electronics, and don't have Python installed on their
computers, can update firmware with a USB cable and a cheap
USB adapter, or possibly just the cable since the adapter
can be embedded on the project's board as in Arduinos.

I've modified the BSLDEMO program used to flash older MSP430
parts so they can now be flashed with a generic adapter, and
I just wanted to do the same for the newer parts that use
BSL-Scripter. Of course TI should be doing this, and I've
suggested as much to them, but to no avail so far.

The benefit of modifying Scripter is that the ultimate user
only needs one file to do the updates, in addition to
installing the adapter's VCP driver if it's not already
included in their OS. I'm just not sure a Python solution
works as well for the general public.

[Peabody]

Paavo Helde says...

> This code just saves and reads a single integer, it does
> not do anything substantial.

I found this thread going back to 2010. The third post
contains code that looks very similar to what I'm working
with, and the author says it works fine. So while I don't
understand it, it appears that this code lets you change the
state of the RTS line. And similarly for DTR.

http://boost.2283326.n4.nabble.com/get-set-RTS-on-serial-port-td2598718.html

> 'initState' is the name of a local parameter, it's
> natural it does not show up elsewhere.

> If TESTControl doesn't either, then it's possible it is
> just some mockup class used only for testing purposes
> and is not a part of the real program.

I understand now about initState. But if TESTControl isn't
called from anywhere in the source, then something else is
causing DTR and RTS to be brought low. Perhaps that's just
the way Boost opens serial ports if FlowControl is None.

In any case, it also seems that my changes could simply call
TESTControl and RESETControl with the appropriate argument
to change the state of these lines.

[James Moe]

On 14/03/2019 4.15 PM, Peabody wrote:

> I don't know anything about BOOST. It appears that something called

> "initState" is key to what's going on here, [...]
>
Not really.
"TESTControl(uint16_t initState)" offers a way to initialize the
internal variable "state" when an instance of TESTControl is created. I
note there is no default constructor; "state" would then be undefined.
Since you cannot find an instance of TESTControl, I would assume it is
unused.

--
James Moe
jmm-list at sohnen-moe dot com
Think.

[David Brown]

On 15/03/2019 16:50, Peabody wrote:
> David Brown says...
>
> > Let's take a step back, and ask what you are actually
> > trying to achieve. If you are trying to program msp430
> > microcontrollers using the BSL, then fiddling with this
> > C++ code when you don't know any C++ is almost certainly
> > the most difficult way to do it. There are several
> > existing solutions for working with the BSL - in
> > particular, there are libraries and programs in Python
> > for the job. If you don't know Python, and you don't
> > know C++, then you'll get further faster by starting
> > with the Python code than with the C++ code.
>
> That's a fair point, and I may be approaching this wrong.
> But the idea is to have a way to flash firmware updates in
> the field, so that people who don't know anything about
> electronics, and don't have Python installed on their
> computers, can update firmware with a USB cable and a cheap
> USB adapter, or possibly just the cable since the adapter
> can be embedded on the project's board as in Arduinos.
>

There is no problem with having Python installed on the user's machines.
If they have Linux, they have Python. If they have Windows, you can
build an exe file with all the bits of Python that are needed. (That
exe file is going to be massively bigger than a C++ sourced exe file -
but do you really care about that?)

You don't even need to touch a line of Python code normally - the tools
already handle many use-cases.

<https://pypi.org/project/python-msp430-tools/>

There are other ready-made tools and libraries on TI's website (not just
the Python ones):

<http://www.ti.com/tool/MSPBSL>


The point is, don't try to program this stuff yourself unless you really
have to. Use existing programs.

> I've modified the BSLDEMO program used to flash older MSP430
> parts so they can now be flashed with a generic adapter, and
> I just wanted to do the same for the newer parts that use
> BSL-Scripter. Of course TI should be doing this, and I've
> suggested as much to them, but to no avail so far.
>
> The benefit of modifying Scripter is that the ultimate user
> only needs one file to do the updates, in addition to
> installing the adapter's VCP driver if it's not already
> included in their OS. I'm just not sure a Python solution
> works as well for the general public.
>

The Python solution has been working fine for developers and end-users
for long before TI thought it might be an idea to release programs
themselves.

Don't get me wrong here - the Python tools are not the only way to do
this, and Python is not necessarily the best solution for all BSL cases.
I simply want you to think more clearly about the situation. Don't
think "I know a little bit of C, therefore the C++ code is the way to
go". Don't think "I don't know much about Python, I can't use it".
Don't think about the limitations you are imagining, but think of a wide
variety of possible solutions before deciding. If you end up using the
C++ code, do so because you have worked through this and seen C++ as the
shortest route to your goals.

[Peabody]

David Brown says...

> You don't even need to touch a line of Python code
> normally - the tools already handle many use-cases.

> There are other ready-made tools and libraries on TI's
> website (not just the Python ones):

I've looked through TI's stuff more than once, and there's
nothing there that addresses the problem. This comes up
repeatedly on the TI forum - Can I flash firmware to an F4xx
(or any of the newer parts) using an FT232 USB-to-UART
adapter with TI's Windows flashing software? Not an
unreasonable question.

And the answer from TI is always - No, we don't support
that. You'll need to use an MSP-FET [$115] or a "Rocket"
[$15]. A generic USB adapter [$1.20] won't work.

As I see it, the problem is really very simple. I don't
need to write a new program. TI has already written and
made available, with source code, software that works
perfectly, so long as you use their proprietary and
expensive hardware interface. Of course there are other
solutions, such as writing your own BSL for the chip. And as
you say, a Python solution may exist. But it just seems
that the obvious solution is to take TI's source code and
make a few minor changes, then recompile, and then it *WILL*
work with those adapters.

I've already done this for the older parts that use BSLDEMO.
It was literally just adding options to invert the polarity
of DTR and RTS. But that was a simple program, written in
C, and I was able to use LCC-Win32 to compile it with a
fairly short learning curve. No BOOST involved.

But BSL-Scripter for the newer parts is more difficult. The
code changes are not really the problem. I think I now
understand the functions that change the state of DTR and
RTS, and last night I finished the changes I needed to add
the option to generate the hardware invoke pattern. It's
just a few lines in four of the 57 source code files. The
problem now is in compiling it.

Here's what I'm up against:

https://github.com/drcrane/bslscripter-windows

I read through the README, and I just have no idea what it
means. The is not LCC, and I don't do this stuff for a
living. I don't have Visual C++, Boost, or any of the other
libraries, nor do I have any idea of how all this works. I
was hoping the process would be less obscure, but I would
spend days, or more likely weeks, learning how all this
works - just to get the existing code to compile, and I
really don't want to do that just for this, particularly
with no prospect of ever needing to use it again.

So maybe the guy who did the repo will compile my changes
for me, but if not, I will probably drop it. If there's an
existing Python solution, people can use that with no input
from me. And there's always a chance that TI will do the
right thing and make this change themselves, which of course
is what really should happen, and which I've asked them to
do.

[Louis Krupp]

There are TI product forums: https://e2e.ti.com/support/

Maybe someone on one of those has built the tool.

Louis

[Peabody]

I was able to contact the guy who posted the Github repo on Scripter, and he
agreed to compile the new version. We've done one attempt, and have one bug
to fix. It looks promising.