DFU - FAIL VERIFY - 8 byte align magic...

[shingadaddy]

Posted on February 13, 2017 at 21:45

So I'm DFU'ing. Successfully bootloading the device with the USB connections on PA11 and PA12 DFU is built into the STM32L476. Plodding along and loading my micro a few times with a few different compilations all good. THEN ---- POOF. One of them won't verify using DFU.

So I try a file that just *DID* work with DFU.

Yep - It worked again ??  WTH over.

Dump the offending file into the device with STLink ---- works.....

I repeat a few things, including inappropriate workplace language and its consistent. (The PROBLEM. Not the Language. I try to mix that up a lot. )

So thinking I have the all singing and dancing IDE (Truestudio), I look for PAD out options. D A R N if I can find it.

So I visit here again (I like it here) and I look here and find

https://community.st.com/s/question/0D50X00009XkdwK/dfu-dfuse-problem-with-stm32l4-stm32l476vg

Really?

Get your HEX EDITOR (XVI32) out and add PADDING?

The word LAME comes to mind. And 'DFU' takes on a whole other meaning. It's inside a 64 bit part for crying out loud.. Why doesn't the BLOWN IN DFU version know that - and ALIGN so the flash programming *blocks* are padded to 8 bytes?

Okay there's the blatant whining and complaining part. Can someone embarrass me with the obvious little tidbit that I *must* be overlooking?

[Kevin Lehzen]

Posted on February 06, 2018 at 17:12

Hi Clive,

it turned out the internal bootloader is the best way to update the F7. Also two separate firmwares, one application and one boot menu, are advisable. In our case the boot menu firmware at 0x08000000 decides whether it jumps to 0x1FF00000 (internal bootloader, i.e. button pressed) or 0x08040000 (application, i.e. button not pressed). Jumping to the internal bootloader just works if there is still a firmware at 0x08040000. In my opinion this is quite mysterious but it works.

At everyone: Always keep an eye on the size of your .dfu file. In our case 0x08010000 (32Kb) was too small for our application firmware with 47Kb.

Thanks again for your help, Clive!

Cheers

Kevin

[shingadaddy]

Posted on February 06, 2018 at 17:41

Ah. Glad you got it!

So the ' 47Kb so that should not be a problem of size ' actually WAS a problem :-)

I can see it looking confusing especially since the '0x10000' part of the '0x08010000 is 64K bytes. That looks confusing to me but I'm not surprised any more when *I* get confused..!

[robcrann]

Posted on May 14, 2018 at 13:05

 ,

 ,

Thanks for the HEX2DFU.exe.

 ,

What to the ,

[-Vid <,VID>,] and , [-Pid <,PID>,] mean?

Also is the Source available so I can build it into a C ♯ application?

Thanks

Rob

[robcrann]

Posted on May 14, 2018 at 13:11

 ,

 ,

Thanks for the HEX2DFU.exe.

 ,

What to the ,

[-Vid <,VID>,] and , [-Pid <,PID>,] mean?

Also is the Source available so I can build it into a C ♯ application?

Thanks

Rob

[Tesla DeLorean]

Posted on May 14, 2018 at 15:40

Source is available for $400 USD

[AvaTar]

Posted on May 14, 2018 at 15:46

What to the 

[-Vid <VID>] and  [-Pid <PID>] mean?

The Vendor ID and Product ID of the USB device, obviously.

[arro239]

Is HEX2DFU 0.01 the latest version?

This tool works great for my F4 firmware but not so great for F7 where I get "ERROR: Image appears to have invalid initial program counter"

Is the source code available anywhere? I would love to get more details on the meaning of "ERROR: Image appears to have invalid initial program counter"

I see stack alignment and stack position are mentioned here. I believe my stack is aligned at 8 bytes

<LINK NO LONGER ACTIVE>

https://github.com/ChibiOS/ChibiOS/blob/master/os/common/startup/ARMCMx/compilers/GCC/ld/rules_stacks.ld

not 100% sure about stack position.

Can you please help me understand what is this about? Is this a limitation of hex2dfu utility or some nuance of using DFU with F7?

[Tesla DeLorean]

Likely looking at how deep into the firmware it is pointing, or if the memory basis for flash is 0x08000000

I didn't release the source. See previous message related to source availability.

[arro239]

Looks like DFU File Manager has converted by hex to dfu just fine and I was able to upload resulting DFU file.

My hex and bin files are available inside https://rusefi.com/build_server/rusefi_bundle_stm32f746.zip if you would have a chance to have a look. Is it expected that if DFU File Manager can convert, hex2dfu should also be able to convert?

[arro239]

I mean I was able "ugrade" my stm32f7 using resulting DFU file, they use "upload" for opposite transfer, sorry if that was confusing