Embedded Project Information into a DFU file and boot image

[nmadinger]

Posted on March 11, 2015 at 20:26

First my plan

I am using the STM32F411, and I am designing a custom boot loader specific to my application.  This boot loader will first of all scan the internal flash memory beginning at address

0x0800C000 for 256 bytes (from 

0x0800C000 - 0x0800C0FF).  I plan on putting project-specific information into this location such as firmware revision, CRC, etc.  If a valid firmware image is found, the boot loader will then read from an external non-volatile memory location (XNVMEM).  If a more recent boot image is found in the XNVMEM, the boot loader will begin programming the flash beginning at address 0x0800C000, otherwise the current application will be used.  If neither the flash, nor the XNVMEM have a valid image, the boot loader will kick off the DFU application and wait for an image to be loaded via USB.

My QuestionsIn short, is there a way for me to put up to 256 bytes of project specific information into the DFU file?  I really want to have some validation string such as: ''This is my project '', the firmware revision number ''X.XX'' and some other useful things.  My second question is, can I jump into the application at address 0x0800C100?  This is where the application program will begin, if I'm able to reserve 256 bytes of project information safe.  Is this valid?Thank you,Noah #boot-loader #dfu #project-info.

[Tesla DeLorean]

Posted on March 11, 2015 at 21:02

Create a small .HEX with your meta-data in it, load it into the DFU image, with the DFU manager. The format of the .HEX is fairly trivial, review.

Seem to recall the vector table needs to be at a 512-byte boundary. You can get the processor to jump anywhere you want, remember that Thumb executable addresses are ODD.

[nmadinger]

Posted on March 12, 2015 at 18:56Thank you for the response.Since posting my first message, I was able to reconfigure Keil to download and debug at 0x0800C100, so I think that I am fine starting the application here.  I'll have to determine this empirically.Now, I have a question on the DFU feature.  Once I am done recieving the new application image from the DFU, how will I know that it is complete?  Upon completion, I would like to jump to start the application (I can also stop petting my external WDT to invoke a reset, but this feels sloppy.)  If there a register I can poll, or a command I can look for to indicate that the new image has been loaded and is ready for execution?

[Tesla DeLorean]

Posted on March 12, 2015 at 19:19

If you are using the System Loader's DFU functionality, it's just going to restart the whole device. None of your code is running.

[nmadinger]

Posted on March 12, 2015 at 22:42I'm afraid I do not understand what you response means.  My boot loader is realized in a state machine.  If the XNVRAM is not valid and there is no image in the INT flash, then and only then, is the USB DFU configuration started.  The DFU is invoked if all previous options fail.  So then, let me say back what my understanding of your comment is.  Once the DFU is finished, it will automatically restart my MCU.  Is my understanding correct?  If that is the case, then upon checking the INT Flash, the bootloader will find a valid image (the one previously loaded by the DFU) and it will jump to this image.  All is well. Would you mind pointing me to the reference that more formally describes this functionality?Thank you.

[Tesla DeLorean]

Posted on March 13, 2015 at 00:11

Ok, where is the code performing the DFU operation? Is this your code, or code in the ROM that you are calling?

If you are calling ROM based code it's not returning too you via the route you call it.

[nmadinger]

Posted on March 13, 2015 at 15:01

Clive,

The DFU code starts at 0x08000000.  It is unclear what you mean by ''

Is this your code, or code in the ROM that you are calling?''

Here is a breakdown of my memory allocation in the Flash:

Boot loader:

0x0800 0000 - 0x0800 BFFF

Project Info. Header: 

0x0800 C000 - 0x0800 C0FF

Application Code: 

0x0800 C100 - End of Flash

Now, both the boot loader and application will use RAM for code execution and peripherals as defined in the reference manual.  These address are simply the location of the storage invoked.

Does this answer your questions?

[Tesla DeLorean]

Posted on March 13, 2015 at 16:00

Many STM32 devices have a ROM based DFU loader, entered at reset via BOOT0=High, or called from application space.

You're evidently not doing that, so basically you can make your DFU loader do pretty much ever you want it too.