Can reset option bytes, STILL can't load firmware

[FLast.3.72]

Posted on October 02, 2016 at 20:39

I have a very basic F103VET dev board, with the schematic. The board arrived running what I guess was ST-Link, which I don't use.  I was able to erase the Flash using the latest FlashLoader (FL) v2.8, via the Cmd line.  I can read and reset the Option bytes. I have followed the rest instructions in doc PM0075. The RDP value is 0xA5 which is supposed to mean flash is now accessible for read and write.

Despite this, I CANNOT load the firmware. Stepping thru FlashLoader in debug shows that the write operation fails on the first 2K page.  I don't have this problem with some seven other F103 board variants, just this one.  The F103VET reports that read (or write) protection is set, and it cannot erase the relevent flash.Any ideas on the cause of this problem? All suggestions gratefully received.  Could it be possible that the manufacturer clobbered something in the chip?  I am resigned to the possibility that the boards are unusable.SD

[Tesla DeLorean]

Posted on October 02, 2016 at 21:04

Provide cites for the board and schematic, the details provided aren't sufficient to guess accurately.

Are you connecting at 9600 baud with EVEN parity ? Are PA9/PA10 free to use or have other connectivity ? Can you connect to the board using SWD/JTAG ?

[Walid FTITI_O]

Posted on October 03, 2016 at 11:41

Hi dibbs.stewart, 

What kind of board you are using ? is that NUCLEO ? What kind of boards where you are not facing the issue ? include F103VET or other device ?-Hannibal-

[FLast.3.72]

Posted on October 03, 2016 at 14:04

Thank you clive1 and Hannibal.   The board is a simply a F103ZET with GPI headers and one LED on PE2. I use 115200 8N on USART1 to connect to the chip boot loader. All this works just fine.

My question is not board-specific, it's chip specific. I can reset the Option Bytes according to the ST doc PM0075, and  using the latest FlashLoader v2.8 (ST download), OptionBytes report RDP as 0xA5 which is no flash protection. i.e. I should be able to load firmware.  This is what I do with a variety of other F103 chips (C8T, CBT, RBT, VET). With this ZET on this board, attempting to load firmware returns an error on the first 2K page, ''Unable to erase flash''. Is this clear enough for suggestions? Have I missed something in clearing the flash? FlashLoader v2.8 does allow all flash to be erased, or at least, does report success at the attempt. I think this does work because the 'as-received'' firmware no longer runs and blinks a board LED. Could it be something about the board itself?

[Tesla DeLorean]

Posted on October 03, 2016 at 15:10

The loader is expecting EVEN parity (8E) not NONE (8N), the errors are not very granular, it is a PASS or FAIL response, and it can give a fail if it doesn't like the checksum, etc. Evalulate behaviour via SWD/JTAG

I'd walk the protocol at a byte level. I don't have a F103VET to evaluate.

[FLast.3.72]

Posted on October 03, 2016 at 20:36

FlashLoader 2.8 list the default COMMS as 57600 8E. Experiments with the commands shows the F103ZET loader is happy with 115200 8E/8O but not 8N. I had not noticed that the default parity is EVEN. I tried the board with 57600 8E and it reports all Flash can be erased, but attempts to erase, say, Pages 0,1,2 fail. A second board, still with the original firmware can be told to run @800 0000  and the LED starts flashing. At present I'm leaving this board as-received. Can't upload flash content to a file on this 2nd board, so whatever the problem is, it's the same for both.

Any more ideas?

[Tesla DeLorean]

Posted on October 03, 2016 at 21:11

Any more ideas?

Not familiar with the board you are using, or the exact method of connectivity. Not hearing if the chip is viable via JTAG/SWD, assuming you've not tried. I'd hazard it is a communications issue, rather than the chip being programmed in some odd state. I'd try to mass-erase part. The System Loader auto-bauds by timing the 0x7F pattern at 8E1, it is not technically ''receiving'' that data, it just responds with 0x79 at baud rate it chose. Lower baud rates may be more robust on cheaper USB-to-CMOS Serial type adapters.

[FLast.3.72]

Posted on October 06, 2016 at 16:47

OK, using JTAG + openOCD I can load firmware. This was the original goal, and the project now moves along, finally. Why the ZET chip won't load using FlashLoader is still unknown, but it's really now a non-issue.   

The firmware I load (@08000000) is a DFU Core Loader and the board appears as a USB STM device in DFU mode. From then on I can load board app firmware via USB above (@ 08003000) the Core loader as needed using another ST utility. Great! NO more JTAG...