Skip to main content
shingadaddy
shingadaddy
Senior
February 13, 2017
Solved

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

  • February 13, 2017
  • 5 replies
  • 6085 views

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?

    This topic has been closed for replies.
    Best answer by Tesla DeLorean
    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

    5 replies

    Tesla DeLorean
    Tesla DeLoreanBest answer
    Guru
    February 14, 2017
    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
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    shingadaddy
    shingadaddyAuthor
    Senior
    February 14, 2017
    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
    Tesla DeLorean
    Guru
    February 14, 2017
    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    shingadaddy
    shingadaddyAuthor
    Senior
    February 15, 2017
    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 8) 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
    Kevin Lehzen
    Associate II
    February 5, 2018
    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:0690X00000609aIQAQ.png

    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 - 0x10000

    FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 1024K - 0x10000

    }

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

    Cheers

    Kevin

    Tesla DeLorean
    Tesla DeLorean
    Guru
    February 5, 2018
    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

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    shingadaddy
    shingadaddyAuthor
    Senior
    February 5, 2018
    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.

    arro239
    arro239
    Associate III
    February 23, 2019

    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
    Tesla DeLorean
    Guru
    February 24, 2019

    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    arro239
    arro239
    Associate III
    February 24, 2019

    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?

    iw2lsi
    iw2lsi
    Associate III
    April 1, 2019

    Hi all,

    I was trying to automate the generation of the dfu file using HEX2DFU (thanks Clive !) file but I got an error message regarding the stack pointer:

    >HEX2DFU.exe blink2.hex -out blink2.dfu
 
HEX2DFU 0.01 Copyright (C) 2013-2017 sourcer32@gmail.com
All Rights Reserved, Non-Commercial Use Only
 
Loading blink2.hex...
02 Addr:0000 Type:04 Seg:00000000
:020000040801F1
Extended Linear 08010000
Basis : 08010000
04 Addr:0000 Type:05 Seg:08010000
:040000050801257D4C
00 Addr:0000 Type:01 Seg:08010000
:00000001FF
VID:0483 PID:DF11 VER:011A
ADDR:08010000 SIZE:00003720
SP:20050000 PC:0801257D
ERROR: Image appears to have invalid initial stack pointer

    but strange enough, nor "DfuSe demo" nor "DFU File Manager" (both at v3.0.6) complains about the stack pointer and even my USB bootloader (that opens an *.dfu from a mass storage device and flash it) seems to work fine... apps are loaded and launched w/o problems.

    My LD files are:

    /* Entry Point */
ENTRY(Reset_Handler)
 
/* Highest address of the user mode stack */
_estack = 0x20050000; /* end of RAM */
 
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x400; /* required amount of heap */
_Min_Stack_Size = 0x800; /* required amount of stack */
 
/* Specify the memory areas */
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
BOOTFLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
APPLFLASH (rx) : ORIGIN = 0x08010000, LENGTH = 960K /* (1024K-64K=960K */
}
...

    so I don't understand where the alignment problem is...

    any ideas ?

    thanks,

    Giampaolo

    iw2lsi
    iw2lsi
    Associate III
    April 1, 2019

    Hi Clive,

    I've found an old message where you suggest to reduce the RAM size...

    it works fine just by changing from the application's LD from:

    _estack = 0x20050000;

    to:

    _estack = 0x20002000; 

    would it be possible for you to update HEX2DFU ?

    tnx

    Giampaolo

    Terms & ConditionsAccessibility statement