cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103RB code OK, STM32F103C8 not OK: alignment?

FLast.3.72
Associate II
Posted on April 30, 2015 at 21:02

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.
2 REPLIES 2
Posted on April 30, 2015 at 21:10

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
FLast.3.72
Associate II
Posted on May 01, 2015 at 16:18

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.