Posted on November 13, 2013 at 08:58I've generally found the system loader to be pretty robust in F1/F2/F4 applications where I have tried it. The STM32F4-DISCO has problems with USART1 PA9/10 due to a large bulk cap on the pins.
One would need to examine the failure at the protocol level and look to see what commands failed and the state of memory at the time.
The loader expects even parity comms (8E1), it bench marks the 0x7F start character to auto-baud the interface, and the USART doesn't actually ''receive'' that character. If the timing up front is marginal, the transfer will be too. We have encountered a number of USB-to-Serial dongles which I'd call marginal, if you have an on-board serial port try that, and other dongles. Perhaps look at installing a serial port monitor app to see what traffic is going on at the failure point, or instrument the Flash Demonstrator code. Here I've been using our own implementation of the protocol.
Often it's not the baud rate, but the stability of it, and whether the dongle uses a crystal, or not. Sending a constant 0x55 bytes, and a scope on persistence mode triggering on the start bit might be illustrative of such issues.
As I spent some time the other week fighting a serial port problem, I might point out if you have a Prolific driver in Win7 64-bit dating from earlier this year you might want to update it, as the driver returns bad/corrupt data with very large transfers (MB). If you close and reopen the com port (CreateFile \\.\COM6 or whatever) the data comes back correctly, where as if the current channel is left open at some point the internal state goes arwy, causing much grief.
