The time is currently 21:42 and I’ve been sitting in front of my computer in 2 hours to get the DFU programming to work.
Now it is working, and I’m able to make one of my excisting projects into a DFU loadable project (compiled it’s a .dfu filed)
I’ve also changed the DFU bootloader code to use GPIOA_0 as DFU Enable pin, and GPIOA_1 as USB Disconnect – this makes me able to use the GPIOB and GPIOC for my display without any interferrance!
Here is how you make a Ride7 project DFU loadable:
The Default Startup script (in settings) has been set to No, as we have included a special startup script in the project (startup_stm32f10x_hd.s – found in CMSIS\Core\CM3\startup\gcc)
Also change the Linker Script in project settings to match the processor group you are using (Connectivity, High Density… and so on – fx stm32f10x_hd_flash_offset.ld)
Also be aware of the change in the NVIC_Configuration – here we tell the processor that the Flash has to start at adress 0x3000
When you have compiled the code to a HEX file, run “DFU File Manager” to create a .dfu file.
Target ID: 00 is Internal Flash
Target ID: 01 is SPI Flash
Target ID: 02 is NOR Flash
Now you can use DfuSe to load the .dfu file into the internal flash of your STM32!
The USB connection between the STM32 and the computer is finally working.
I’ve tried the different USB programs from the StdPeriph Library
- Virtual COM Port
- DFU Programming
As I’m using Ride7 for programming, I can upload the project and sources if you want me too.
OBS: If you have projects which DOESN’T use the USB, you have to set the USB Disconnect jupmer to Ground (Pos. 1-2), as if not, the STM32 will stop in some kind of USB Interrupt trying to make a data communication with the computer, but it never comes as the STM32 doesn’t start one!
I discovered this Ã‚Â when I tried DFU’ing my 320×240 LCD code – and when I went back to normal .hex, it didn’t work – that was because I had to set the USB Disconnect to Ground!