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?

[Tesla DeLorean · Accepted solution]

Posted on February 14, 2017 at 02:41

Attached is my HEX2DFU command line tool. It should take a .HEX and do the alignment padding.

Usage : HEX2DFU <.HEX file> [-out <Filename>] [-Vid <VID>] [-Pid <PID>]

________________ Attachments : HEX2DFU_REL001.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyvm&d=%2Fa%2F0X0000000bE0%2F1aSrA2Yt_czWjaAp2_eI.fNL7h3znsZpWxzDp.AA9Jg&asPdf=false

[shingadaddy]

Posted on February 14, 2017 at 21:28

clive1, this is awesome. Very generous.Thank you. And the very thought quickly entered my head about doing just this - but then --- I had that EPIPHANY moment. ...It was like --- HOLD IT.. .WHY WOULD I NEED TO DO THIS?

And to clarify my first post here, just in case anyone mistook my meaning, its awesome that the fix is at hand. The generosity is awesome here in the forum AND at ST .Even the HAND EDIT thing is fine and a perfectly viable fix. Not LAME at that point at all. I guess I was taken by the questions that sort of EXPLODED into my head.

1. Why didn't the DFU FILE MANAGER converter do this?

2. And more pointedly since its INSIDE the very device - why doesn't the internal built in DFU bootloader code in the device, handle this natively.

That was where the LAME was targeted - but it was during a flurry of frontal activity. It could be worse I guess , with NOTHING at all offered.

Thanks again

[Tesla DeLorean]

Posted on February 14, 2017 at 21:43

This evolved out of a discussion last week, here

https://community.st.com/0D50X00009XkYcRSAV

Had to clean it up and give it more generalized function, the padding seemed like an easy addition as I was already removing 0xFF slack space.

[shingadaddy]

Posted on February 15, 2017 at 20:45

clive1's routine cleverly uncovered that I had stepped in a familiar hole that has been circulated here in the forums before so beware of your Linker SCRIPTS ( *.LD file -  mine being  STM32L476ZG_FLASH.ld ) setting your stack pointer to a non 4 (or 😎 byte boundary. Mine was set to

_estack = 0x20017FFF;    /* end of RAM */     <---------  That caused clives routine to complain about the stack pointer setting being invalid for my STM32L476 (M4 part)

_estack = 0x20018000;    /* end of RAM */     <---------  That FIXED it

AND -----  The DFU DEMO loader VERIFY function is HAPPY now also. ---- MAKE NO MISTAKE HERE - THAT was just LUCK.

Apparently I was 1 byte short in the binary which caused the DFU to not verify. By bumping the stack by 1, it

1. Made both the starting point of the stack aligned (made clives routine happy )

2. Made the DFU verify correctly (the newly generated hex / binary landed on alignment boundary)

I confirmed this by using a compilation that the DFU loaded AND verified okay, which also used the estack set to the offending 0x0x20017FFF

I then checked this with clive1's utility and it reported the 'ERROR: Image appears to have invalid initial stack pointer' message.

And yes - it seem to run okay after loading but I suspect in performance testing it, it probably runs like it has square wheels -- whereas if on

boundary, it would probably run like real ROUND wheels. Probably..

Thanks much to clive1 and the many contributions he has provided.

[Kevin Lehzen]

Posted on February 05, 2018 at 14:10

Hi there,

we are having the same issue with not matching addresses in DfuSe. We are using the STM32F746VG on a custom board. With the HEX2DFU converter we also get the same error with the initial stack pointer:

We tried different configurations for _estack in the .ld file. Below is our current configuration but we also tried 0x20050000 and 0x2004FFFF.

/* Highest address of the user mode stack */

_estack = 0x2004FFF0; /* end of RAM *//* Generate a link error if heap and stack don't fit into RAM */_Min_Heap_Size = 0x200; /* required amount of heap */_Min_Stack_Size = 0x400; /* required amount of stack */

/* Specify the memory areas */

MEMORY{RAM (xrw) : ORIGIN = 0x20010000, LENGTH = 320K - 0x10000FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 1024K - 0x10000}

Do you have any ideas to get a valid initial stack pointer?

Cheers

Kevin

[Tesla DeLorean]

Posted on February 05, 2018 at 15:03

Actually it was my utility, might be the SRAM address is too high for the purposes of the sanity check.

Could you try changing the address in the vector table in startup_stm32f7xyz.s?

g_pfnVectors:

  .word  _estack   /* Change to 0x20002000 */  .word  Reset_Handler

  .word  NMI_Handler

  .word  HardFault_Handler  .word  MemManage_Handler

...

The first instruction in Reset_Handler sets it to _estack so just needs a RAM bound address, probably at 128KB or below

[shingadaddy]

Posted on February 05, 2018 at 17:16

I've not had any further issue so I won't be much help since I didn't dive in any deeper than I explained earlier. And Clive1 threw me a lfe preverver in that case. Not sure if it would help with anything or not but I suppose you could get your hex editor out and try adding pads just to see if you CAN make it happy with that method. That might uncover some other oddity that might be throwing the same warning. Just a shot in the dark really. From the hip.

[Kevin Lehzen]

Posted on February 05, 2018 at 17:04

Hi Clive,

thanks for the fast reply. The conversion worked fine but still there is a mismatch in DfuSe as you can see here:

The generated .dfu file is 47Kb so that should not be a problem of size. VECT_TAB_OFFSET was already changed to 0x10000. Also I can download the same .dfu to my discovery board but not to my custom board. The only differences are the package (disco = BGA-220, custom = LQFP-100) and the mapping: 

The bootloader on the disco board is the DFU_standalone example of ST's drivers. Any ideas? Maybe we should use another driver version? Currently we are using STM32Cube_FW_F7_V1.8.0.

Cheers 

Kevin

[Tesla DeLorean]

Posted on February 05, 2018 at 17:13

The FLASH banking in the working vs non-working examples is different.

Look at what's going on with the options bytes.

The 3.0.5 version of DfuSe demo predates the F7, perhaps try the all-in-one utility that ST release recently.