2016-12-13 10:43 AM
I am using STMFlashLoader Demo v2.8.0
I recently upgraded as I am bringing up a new board design that uses STM32F427. I am unsure if these issues exist in previous versions, but the first issue probably does.
Issue 1) There is a problem where STMFlashLoader apparently does not properly configure the Windows DCB to configure the serial port to No Handshaking. If you run another program with handshaking enabled on the serial port, then close that serial port, then run
STMFlas
hLoader Demo; the program will fail to connect to the board. A workaround is to run another program before STMFlas
hLoader Demo that allows you to open the COM port and specify No Handshaking, then close that port, then run STMFlas
hLoader Demo. This will then allow the program to connect to the board (system memory boot mode of course). I have observed this by running a number of different programs prior to STMFlas
hLoader Demo, but for reference you can use Tera Term to create the problem and to correct the problem prior to running STMFlas
hLoader Demo. I am using software handshaking, but it appears that hardware handshaking has the same issue.
Issue 2) This may or may not be unique to the STM32F427. I am specifically using STM32F427IIT6. After the program connects to the board and I navigate to the programming page, if I select 'Erase' or specify a HEX file and select 'Download to device', the erase fails with 'FAIL: Unable to erase flash'. At this point, the previous firmware on the device is trashed. If I go back to the programming page and run 'DISABLE WRITE PROTECTION', I am then able to program the device. Two things are strange about this: First, if write protection was enabled then why does the erase operation ruin the existing program. Second, I have not enabled write protection anywhere and I am able to upgrade the firmware using DfuSeDemo via the USB port with no complaints about write protection. I have used a previous version of STMFlas
hLoader Demo with a STM32F407 without having erase problems or write protection issues.
Comments?
2016-12-13 11:33 AM
I didn't see a way to edit my original post. An additional symptom of Issue 2:
If you run 'DISABLE WRITE PROTECTION' and then exit the program before programming the device, when you run
STMFlas
hLoader Demo again you must again run 'DISABLE WRITE PROTECTION' prior to programming or erasing the device. Whatever this is doing, it does not carry over to the next time running the program (note you need to reset the board the next time you run in order to connect).
I am using Windows 7 Professional 64-bit
2016-12-14 03:48 AM
Hi Tut. You are using an external PC serial port (UART) to communicate with your target STM32 CPU for flashing ? Please share the details of this external UART. Is it USB based ?
Regardless, review the pinout of this external serial port and check if there are RTS and CTS lines. If yes, mate them together and the serial port will always be true and then the use of hardware flow control will become a no care condition.
2016-12-14 06:07 AM
Hi, thanks for the response.
I have been testing with a native serial port on a Dell Precision T7600 desktop PC. I have also observed the problem using a plug-in PCI serial port expander (PCIe to High Speed Serial Port).
As I mentioned I already have a workaround, but will try your suggestion later if I get some time. A couple points regarding your suggestion:
1) I have been running an application that uses software handshaking, which after closing will result in STM32FlashLoader Demo having the connection problem.
2) The source code for STM32FlashLoader Demo indicates they are attempting to turn off handshaking as they should. They apparently are not doing it correctly.
In main() (STMFlashLoader.cpp) they have:
bool control = false;
and later
STBL_SetFlowControl(control);
In STUARTBLLIB.cpp they have:
STUARTBLLIB_API BYTE STBL_SetFlowControl(bool val)
{ Cur_COM.FlowControl= val; return SUCCESS;}In the function CRS232::open() (rs232.cpp) they have:
if ( FlowControl == true)
{ dcb.fDtrControl = DTR_CONTROL_ENABLE; dcb.fRtsControl = RTS_CONTROL_ENABLE;}
else {dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fRtsControl = RTS_CONTROL_DISABLE; }On applications I have written which have not experienced problems, I have disabled flow control with:
dcb.fOutX = FALSE; // No xon/xoff used
dcb.fInX = FALSE;dcb.fDtrControl =
DTR_CONTROL_DISABLE
;dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = FALSE; dcb.fTXContinueOnXoff = 0;For more info google: windows dcb
In my opinion Windows should (but apparently doesn't) default to no handshaking. There should be no residual effects from the last program using the COM port.
2016-12-14 08:29 AM
The application should configure the port into the mode it wants it. Windows just maintains the current settings if not changed properly.
You can Edit your posts via the 'Action' option when you are in the singular thread view (left corner of post), this is not available in the multi-thread digest view. If you are in the digest view, click your thread title to get the singular view.
2016-12-14 09:58 AM
'
The application should configure the port into the mode it wants it.'
... Yes, and ST is not fully configuring the DCB for no handshaking. I think if they add the lines as I have indicated above, the problem will probably be resolved. Unfortunately I do not have the tools to re-compile the source code to try it.
2016-12-14 11:22 AM
I didn't remember it before, but my board already provides loopback of the control signals so no help there. I can run Tera Term and enable hardware handshaking on the port, then exit and run STMFlashLoader Demo and it fails to connect (despite the loopback), but if I run Tera Term and set flow control to 'none' and close, STMFlashLoader Demo will then connect.
By the way, my loopback connects pin 4 (DTR) to pin 6 (DSR) and to pin 1 (DCD), as well as connecting pin 7 (RTS) to pin 8 (CTS). (DE-9)