AnsweredAssumed Answered

Interplay of DFU bootloader and Applikation

Question asked by poppen.frank on Nov 24, 2011
Latest reply on Nov 25, 2011 by Tormod
Sorry for posting this as newbe, but I'm browsing all the PDFs I found and used all the search queries relevant on this forum without result. My Problem inshort first and then long.

SHORT:
-Purchased evaluation board STM3210B-EVAL
-downloaded um0435.zip (STM3210B-EVAL_FW_V2.0.0)
-downloaded included DFU with DfuSeDemo.exe (OK!)
-used file manager DFU -> HEX and then back HEX -> DFU. after download still (OK!) - Conclusion files and tools are working properly.

Problem:
- Opening the RIDE project of Demo (STM3210B-EVAL_Demo.rprj). Version 7.30.10.0159
- build is OK, HEX generated. HEX -> DFU OK
- after upload device does not leave DFU mode after RESET. (Leaves, but goes right back into it).

Assumption: Generated HEX does not work with bootloader. Startaddress wrong (or so?) How to generate HEX that works with DFU bootloader? Why does the demo not work out of the box as should be (for a Demo!)? Thanks for any help and link to further
documentation.

Longer Comment:
I can sucessfully download the delivered demo application HEX to the evaluation board and have the nice slide show etc running. But if I compile the delivered demo from delivered source and RIDE project (runs without problem) the generated HEX converted to DFU does still dowload, but is not started. The device always goes back to DFU mode.

Reading everything I found I today believe that my application should start at address 0x800003000? But why is the demo projects configured at 0x800000000? Or should it be there? I do not see a way to change the startaddress in the RIDE7 development tool.

Somewhere here must be a nice "How to start your HelloWorld with DFU bootloader!" but I'm not able to find it, sorry.

Thanks for any help.

Outcomes