Trying to load non-USB application to STR750FV2 with ST DfuSe Demo

[mige]

Posted on September 19, 2012 at 00:43

As the thread title states, I am attempting to use the ST DfuSe demonstration software to perform a firmware update to the flash of an ARM7 device (STR750FV2) for the purpose of installing and running a working non-USB application.  At my office, we have a STR750FV2 development board from Raisonance, the Reva V2.10 board with STR750 daughtercard.  We use it with the Ride7 program (V7.28.10.0075) running on Windows XP.

I began by downloading the STR7/STR9 USB Developer Kit from the ST website (UM0290.zip, containing V2.0.0) and from that I obtained the Device Firmware Upgrade project material for RIDE.  I was able to compile the DFU source code and run the linker to come up with a .hex file, which I successfully loaded into the STR750FV2 device on the Reva through its JTAG interface.

On the PC host side (running Windows XP), I installed the DfuSe Demo package (UM412.zip, containing V3.0.2, downloaded from ST website).  Then I connected the STR750FV2 device (already programmed with the DFU application by JTAG) via the Reva board's USB link, and the PC host immediately saw the USB connection and auto-installed the DFU driver, which showed up in PC host as ''ST Micro Device in DFU mode.''  Additionally, the DfuSe GUI in Windows indicated that the ARM7 was detected as an operating DFU device.  So far, so good.

For a working test application, I compiled and linked a sample RIDE project which blinks some LEDs on the Reva board.  This simple blinking LED program is the non-USB application I am trying to load into the STR750FV2 through DFU.  I can load it to the ARM7 through JTAG, and it runs fine as a stand-alone program.

So far, however, I am unable to get this non-USB application to load and run on the ARM7 using the DfuSe Demo GUI to program it via DFU.

The first question is pretty basic.  Does the DFU application included in UM0290.zip in conjunction with the DfuSe Demo software in UM0412.zip allow STR750FV2 users to load, and then execute, application code (i.e. blinking LED program) using the DFU protocol?  I have tried this (making sure to first create a .dfu file for the non-USB program's .hex data), but have been unsuccessful thus far.  Hence this initial query -- is what I am attempting even possible for the STR750FV2 when using the DFU materials from UM0290.zip and UM0412.zip?

Thanks in advance for any insight or feedback.

[Tesla DeLorean]

Posted on September 27, 2012 at 02:31

http://forum.raisonance.com/viewtopic.php?id=4732

Thanks in advance for any insight or feedback. It's been a while since playing with the STR7's, but a quick look at the DFU code suggest you should be able to create arbitrary code that can be uploaded and run. For a GNU based platform it assumes the code you generate will live at 0x20006000 (0x20004000 for Keil/IAR). Code built for 0x20000000 will FAIL

[mige]

Posted on October 30, 2012 at 20:47

@clive1,

Sorry about the tardiness of this acknowledgement, but thank you for your response.  And thanks for the link, although as it turns out, I posted that one on the Raisonance forum prior to registering here on the ST forum.

As you correctly stated, the start address of the application was the cause of the problem.  I had improperly compiled the project with the starting address set to 0x20000000.  I have since edited a project linker file in RIDE so that subsequent builds begin at 0x20006000.

Now the resulting .hex file can be converted to a .dfu file, then downloaded into the ARM flash (using ST Micro's DfuSe Demo for Windows), and the application -- a simple program that blinks LEDs on the development board -- actually works on the next ARM reset or power cycle.

This is breakthrough for me, and I would like to say ''thank you'' for your assistance.

So now it is time to go to the next step.  The next step is to be able to use the DFU as a bootloader, which it appears to be by design.  The DFU application begins at address 0x20000000, while the ''blinking LED'' application begins at address 0x20006000 (both reside in the ARM internal flash 0).

When the ARM is powered up (or is reset), the DFU bootloader would start first.  If there is no USB connected to a host machine for performing firmware upgrades, then the ARM bypasses the DFU application (does not enter DFU mode) and goes into application mode instead.  If, however, on power up or reset a USB connection to a DFU host machine is in place, then the ARM is initiated in DFU mode for performing firmware upgrades.

The problem, unfortunately, is that I do not know for certain if this is how ST's DFU project was designed to operate.  All I know is what I have observed, which is this...

- A full ARM flash erase is performed,

- the ST DFU application is downloaded via JTAG, - the ST DFU interfaces properly with the PC host (running DfuSe Demo in Windows), - the ''blinking LED'' application is converted from .hex to .dfu, - the .dfu is downloaded into flash through the DfuSe Demo, - the LED application always starts upon ARM reset or power cycle, regardless of whether or not there is a USB connection to the PC host.  DFU mode is functionally ''disabled'', even though it still resides in ARM flash.  (Note: when the USB is connected to the PC host, Windows says ''Attached USB device is unrecognized by Windows.'')

So, in short, DFU only works once in my case.  Once an application is downloaded into the flash, the ARM will never enter DFU mode again.

Has anyone else ever succeeded in using ST's DFU application as a bootloader that can initialize in the DFU mode (upon ARM reset or power cycle) instead of always going into application mode?

Thanks again to the ST forum community for all the helpful discussion.