Question and problem on how to use DFUse utility and DFU program

[Vu.Andy]

Posted on August 17, 2016 at 18:29

This is sort of a two part question.  One for the USB DFU example program and one for the DFUse utility and.

I have built the USB DFU utility program and downloaded to STM32F4 board.  I also downloaded the DFUse utility.  The board is recognized by Microsoft as DFU from Device Manager.  So I think everything is good so far.

I built the example Toggle_IO and converted to DFU format using STM program.

So now I use the DFUse utility to download the program.

Now the PROBLEM is after I downloaded the Toggle_IO program, there is an error message

''Matching not good.  First Difference at address 0x08000000:

  First byte is 0x60

  Read byte is 0x10.

''

But address 0x08000000 is of the USB DFU program, not the Toggle_IO.  Toggle_IO is supposed to be downloaded at address 0x08008000 according to the USB DFU.  I am not sure why the DFUse utility is checking address 0x08000000.  Should it be checking address 0x08008000.  This makes me think that the DFUse. utility is only meant for the build-in USB DFU program which resides on the ROM portion that is shipped with the device that downloads program to address 0x08000000.

So if I use the example USB DFU program, which software program can I use to download program?

I checked the content at address 0x08008000 but it does not have the correct content of the Toggle_IO program so it seems like either Toggle_IO was never downloaded or downloaded at some other locations.

Could anyone help?

Thanks.

[Tesla DeLorean]

Posted on August 17, 2016 at 18:54

The DFU utilities take addresses *you* provide.

You *must* build the code you supply so the linker outputs a .HEX file that is situated at 0x08008000. Clearly you are not doing that, and there lays the problem.

[Vu.Andy]

Posted on August 17, 2016 at 22:43

Thanks for the help.  That works. 

But now there is an interesting issue.  The Toggle_IO example program would toggle the LED on and off using a delay function HAL_Delay(100) which in turns uses SysTick_Handler(void).  I pasted the codes below.

But in this DFU mode, the Toggle_IO would only turn on the LED once because

HAL_Delay(100) never returns which I think because there is some conflict with SysTick_Handler(void).  The DFU portion has its own SysTic handler and the Toggle_IO has its own SysTick_Handler().  So which one will get called?  As far as the CPU is concerned, there is only one program but it seems they have two separate resources but with identical convention.

It seems to me the SysTick_Handler() never able to advance the counter on the Toggle_IO program so the HAL_Delay() program would just get stuck.

That is my guess what's happening.  If I replaced HAL_Delay() in Toggle_IO with a long for() loop when the LED would toggle.   So I think everything works, except that the interrupts have some type of conflict.  How would that get resolved?

I can imagine the DFU and the Toggle_IO both have their own stack and heap space so how that will get resolved since these two programs are built separately.

Thanks.

  while (1)

  {

    HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_0);

    /* Insert delay 100 ms */

    HAL_Delay(100);

        

  }

void SysTick_Handler(void)

{

  HAL_IncTick();

}

[Tesla DeLorean]

Posted on August 17, 2016 at 23:04

You need to make sure that the address you set for the Vector Table reflects the new address you are placing it. This is typically done in SystemInit(), system_stm32f4xx.c and writing to SCB->VTOR

The value written now needs to reflect the 0x08008000 base

[Vu.Andy]

Posted on August 17, 2016 at 23:45

Thanks for the feedback again.  It seems like there are quite a few changes that need to be made and can be very risky if not done correctly especially for a new programmer not knowing all the details of memory allocations and so on.  It's more than just loading a new program into a memory space without considering the hardware resources.

To me the this example is probably a good exercise demonstrating the ability of a DFU USB program but not practical in a real application.  A real DFU probably will need a lot of careful thinking and designing ahead of time to make sure all the interrupts and memory locations are done taking into account the user application.

[Tesla DeLorean]

Posted on August 18, 2016 at 01:52

The issues here are really ones of clarity about how the core behaves, and the interactions between the code, compiler and linker. The DFU side of things would probably need refinement if delivering to an end customer for a product, but then you might be writing your own drivers, and windows apps to support that effort.

The code ST provides isn't that sophisticated, I've rewritten portions to use the __Vectors symbol to automatically set up the correct VTOR, better fail-over for the HSE and code to read the Chip ID and automatically set the PLL and wait-states. This way it can run at maximal speeds on 401, 407 and 411 without worrying.