#82 Improved DTR and RTS initialization

[Ernst]

When using the -i DTR / RTS options, stm32flash failed if
another application (terminal program etc.) left DTR / RTS
in the DTR_CONTROL_HANDSHAKE / RTS_CONTROL_HANDSHAKE
mode. MS documentation specifies:
If handshaking is enabled, it is an error to
adjust the line by using the EscapeCommFunction.

[Tormod Volden]

Thanks for your patch! It seems to make sense, although I don't know Windows so well. Do you have a link to this documentation?

[Ernst]

Heres a link to the Microsoft page where the DCB is documented.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363214(v=vs.85).aspx
In case the link should ever get broken in the future, searching for "fRtsControl fDtrControl" will do.

[Antonio Borneo]

Yes, this patch makes sense!
I don't use Windows, so cannot fully debug this part.
Do you think we should also set:
fDsrSensitivity = FALSE;

[Ernst]

I agree, fDsrSensitivity may cause problems, too, it it was left active by a previously run application.
After looking at the initialization code, I think perhaps it would be better not to copy the existing settings to newtio with the GetCommState(h->fd, &h->newtio) call, but let them at the initial zero values and set only the required parameters. Then we would not need to care for exotic handshaking options, the defaults when set to 0 look reasonable. Unfortunately, I cannot test it easily, but I think it can be risked to simply remove the GetCommState call, a zero value at least gives reproducible results instead of being dependent on the settings left by another application.

Edit: Of course, the DCBlength field has to be set to a correct non zero value...

[Antonio Borneo]

Agree that using a "freshly" initialized newtio will give reproducile results.
But then other fields must be initialized, like DCBlength, fBinary, ...
Maybe you could use as an initial reference the value you dump from a working newtio.

[Ernst]

After further reading, I changed my mind, I think starting with a zeroed newtio is a bad idea due to the 'reserved' fields.
Microsoft explicitly recommends modifying the DCB returned by GetCommState:
"To set only a few members of the DCB structure, you should modify a DCB structure that has been filled in by a call to GetCommState. This ensures that the other members of the DCB structure have appropriate values." [1]
and does so in the example [2].
BTW: In [2] they initialize the DCBlength field before calling GetCommState, in [3] (Windows CE, but the same API) they explicitly demand initializing DCBlength.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363436
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363201
[3] https://msdn.microsoft.com/en-us/library/aa450503.aspx

I extended the patch to initialize fDtrControl, fDsrSensitivity, fTXContinueOnXoff, fErrorChar and fRtsControl, and to init DCBlength before calling GetCommState.

This change was tested only to be cross-compileable for Windows and not tested with an STM32 device connected to a Windows system.
The Patch replaces the patch in the initial posting.

[Tormod Volden]

Any chance you can test this soon? I am about to prepare a new release and I won't include untested patches at this point...

[Ernst]

Tested on Win7 with FTDI adapter, works as expected.

[Tormod Volden]

Thanks for the testing! I have pushed this to git. I will try to get some testing done on Windows myself (on CP210x and PL2303 adapters). Well, if I get past bug #85, or native MinGW works.

[Tormod Volden]

I have tested on Win7 with CP2102, CP2104 and PL2303 adapters and everything looks fine (connection and reading from a STM32F4 board).