2015-04-30 12:02 PM
I have two almost identical 72MHz boards which have code issues I suspect are related. I have DFU firmware that loads on to both boards, and both appear to the host as a USB DFU device.
App firmware is loaded at 0x08003000, with NVIC_Relocate(); to set the jump point. On the STM32F103RB, I load the DFU code, and erase all the FLASH, then load the app firmware. The board reboots and appears as a fully functional HID device as intended. A jumper if fitted causes the board to boot up as the DFU device. If I load the same app firmware again, when the board reboots the app code fails in some way, and the HID device does not appear to the host. Fixing this requires the DFU (with erase) and app reloading. This is very odd, as the same app binary is loaded at the same address, using the same utility. I would have expected the app to work as before. It's as though the rewrite/overwrite is failing or writing elsewhere. On the STM32F103C8, essentially the same app firmware is loaded, with only variations in the GPIO pins activated. I've checked this many times, and can comment it all out to no avail. The HID device does not appear to the host at all. I can fit the DFU mode jumper and USB DFU mode will restart as intended. I'm not aware of any major differences between the F103C8 and F103RB other than the flash size. So far as I can tell, the clocks (RCC stuff) are being set properly. I'm wondering if the code alignment is the issue. Some experiments with #pragma data_alignment=4 have had no effect. All ideas and suggestions are welcomed.2015-04-30 12:10 PM
Not going to pull the data sheets, but do the devices have different Flash BLOCK sizes?
Look for that as the part/chip define passed into the compiler, and where it's used in the flashing code.2015-05-01 07:18 AM
Found it! I use the DFU firmware sample code (modified to suit) and the ST DFuse loader app (also with Windows C++ source). In the firmware, there's an interface string that defines the device flash size and the amount of DFU loader code are reserved. The DFuse loader app reads this string and adjusts the .dfu binary in some way. For example, with a 0x3000 reserved area in all cases...
STM32F103VET (512K flash) uses /0x08000000/6*002Ka,250*002Kg STM32F103RBT (128K flash) uses /0x08000000/12*001Ka,116*001Kg STM32F103C8T (64K flash) uses /0x08000000/12*001Ka,52*001Kg Note the flash page size differences, and that the number of defined pages total available flash for the target. Rebuilding the DFU loader binary with correct strings now has all boards working properly.