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 STMFlashLoader Demo; the program will fail to connect to the board. A workaround is to run another program before STMFlashLoader Demo that allows you to open the COM port and specify No Handshaking, then close that port, then run STMFlashLoader 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 STMFlashLoader Demo, but for reference you can use Tera Term to create the problem and to correct the problem prior to running STMFlashLoader 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 STMFlashLoader Demo with a STM32F407 without having erase problems or write protection issues.