cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 does not reset after DFU by USB

CHABIN.Laurent
Associate II
Posted on November 17, 2017 at 20:27

I have already read several posts about the subject. including 'DFU: LEAVE does not jump to application'.

and 'Reset after firmware upgrade'

Context : 

STM32F072RB

using either DfuSeCommand.exe or DfuSeDemo

Using the DFU USB bootloader in system memory, started by sw from the main app.

Using DFU files

My API does not manipulate in any special way the vectors tables. Everything is standard from an auto generated  STM32CubeMX project.

My program is only in flash at 0x8000000

My need is basic and already discussed in other threads, yet I do not understand why this is so complex to solve that problem. Isn't there a little exec that does that in command line ? Or the problem is in my code ?

DfuSeCommand does work and upgrades using a DFU file, but does not make anything to leave the DFU mode.

My final need I want to modify DFuSeCommand so that it resets the chip.

However there is a sign that it is not that simple to do.

Using DfuSeDemo, after a DFU, clicking on 'Leave DFU' displays 'Successfully left DFU Mode!' but just makes the USB device disappear (nothing seen by USBLyzer (usb snifer)) as if the CPU had been reset or stalled, but not properly reset.  

As far as I understand, notes 1 and 2 of AN3156 do not apply to me

Note 2 says : 'this procedure is not needed after exiting system memory boot mode'. Am I right if I say that 'Leave DFU' makes the CPU exiting system memory boot mode ? If yes, note 2 does not apply to me.

Note 1 says 'The Jump to application works only if the user application sets the vector table correctly to

point to the application address' I don't understand that in my context. How could I set the vector table since we are running the system memory bootloader ? And in any case, 

Notes 2 says : 'reset the core'.  how do i reset the core ? I would be very surprise if it was by a 

NVIC_SystemReset();  since I would have to manage to avoid an infinite reset loop.

Then, what is wrong ? 

For the community, my useful code for starting DFU by SW

It works, but I need to cycle the power. That's my problem.

(Arm Keil)

/*

See CD00167594 p20

In addition to patterns described above, user can execute bootloader by performing a jump

to system memory from user code. Before jumping to Bootloader user must:

� Disable all peripheral clocks

� Disable used PLL

� Disable interrupts

� Clear pending interrupts

F0 : Memory Location 0x1FFFF6A6

bootloader firmware 12kb from 0x1FFFC800

USB DFU : PID = 0x448, BLID = 0xA1

*/

Since my  

__initialize_hardware_early() 

is called just after power on reset, or a

NVIC_SystemReset(),  

I can assume that this is the case, right ? And by the way, the USB DFU works. It is the return from it that is a problem.

startup.s extract

; Reset handler routine

Reset_Handler PROC

EXPORT Reset_Handler [WEAK]

IMPORT __main

IMPORT __initialize_hardware_early

LDR R0, =__initialize_hardware_early

BLX R0

LDR R0, =__main

BX R0

ENDP

code.c

&sharpdefine SYSMEM_RESET_VECTOR 0x1fffC804

&sharpdefine RESET_TO_BOOTLOADER_MAGIC_CODE 0xDEADBEEF

&sharpdefine BOOTLOADER_STACK_POINTER 0x20002250

// do not initialize these ones

volatile uint32_t dfu_reset_to_bootloader_magic __attribute__( ( section( 'NoInit'),zero_init) ) ;

void __initialize_hardware_early(void)

{

   if (dfu_reset_to_bootloader_magic == RESET_TO_BOOTLOADER_MAGIC_CODE)

   {

    void (*bootloader)(void) = (void (*)(void)) (*((uint32_t *) SYSMEM_RESET_VECTOR));

   dfu_reset_to_bootloader_magic = 0;

    __set_MSP(BOOTLOADER_STACK_POINTER);

    bootloader();

    while (42); // NVIC_SystemReset(); instead seems to change things a little if a flash upgrade is indeed done. But that's quite random. How come the bootloader returns, shouldn't it reset when you leave ?

   }

   else

   {

     SystemInit();

   }

}

void startDFUMain(void)

{

  dfu_reset_to_bootloader_magic = RESET_TO_BOOTLOADER_MAGIC_CODE;

  NVIC_SystemReset();

}

#dfu #reset
3 REPLIES 3
CHABIN.Laurent
Associate II
Posted on November 17, 2017 at 20:31

When I write 'STM32 does not reset' I actually mean that I observe that the chip does not properly reset, since it does not enumerate at all as a USB HID device, which is what my API does. USBLyzer sees : nothing on the USB port.

If I then cycle the power, the

USB HID device

 comes back.
Frank Razenberg
Associate
Posted on June 29, 2018 at 12:13

I noticed similar behavior. My solution was to enable IWDG to trigger in say 250ms. After DFU leave command is sent, bootloader ceases to reload IWDG so proper reset occurs quickly after.

Hi,

Can you elaborate on your solution?

What's DFU leave command?

Is WD works while in bootloader?

Thanks