Application fails to start after DFU leave

[sylvain]

Posted on February 10, 2016 at 01:22

I've got an STM32L15x whose application sets a ram flag then does a soft reset, after which the startup code jumps to the DFU bootloader. So far so good, the DFU kicks in and the host PC is successfully talking to it and pushing new firmware (validated by reading back using ST/Link.)

However, it's very inconsistent from run to run, or PC to PC, or firmware to firmware (no patterns) but the newly flashed application often fails to start following a DFU leave/exit and we can't recover it until the battery drains.  This is a major issue since the unit is sealed and we can hard reset.Anyone any idea ? #stm32 #dfu #bootloader

[Tesla DeLorean]

Posted on February 10, 2016 at 04:47

The first step I think would be to understand what is happening, and how it is failing. I'd probably start with some USART output initialized as soon as it gets into the Reset Handler code, and get some telemetry from there.

If the device has to reconnect via USB, you might want to look at what's going on with the interface's pins, and if there are any timing issues, or issues with clocks or PLLs coming up, and any expectations the device has for being in a truly reset state, vs hot starting out of the DFU loader.

[sylvain]

Posted on February 11, 2016 at 01:53

As a workaround, we've added a soft-reset in the startup code and it seems to do the trick.

We haven't yet found what is exactly causing the issue...

[sylvain]

Posted on February 19, 2016 at 00:41

For anyone else having similar issue...

We've been working with STM to figure out what was happening.  In short, this is a side-effect of the application using USB and not resetting the usb core on start.  Here is an excerpt from the AN3156: ''

When performing a jump from the bootloader to a loaded application code which uses the USB IP, the user application has to disable all pending USB interrupts and reset the core before enabling interrupts. Otherwise, a pending interrupt (issued from the bootloader code) may interfere with the user code and cause a functional failure.

''STM provided us with the following snippet to add to the beginning of code:

  SystemClock_Config();

  HAL_NVIC_DisableIRQ(USB_LP_IRQn); 

  __HAL_RCC_USB_FORCE_RESET();

  __HAL_RCC_USB_RELEASE_RESET();

  /* Init Device Library */

  USBD_Init(&USBD_Device, &VCP_Desc, 0);

Thanks to Joe@STM :)

[re.wolff9]

Posted on February 20, 2016 at 17:34Onother thing that you may or may not encounter is: The internal RC oscilator is trimmed for 7.2MHz, instead of 8MHz when exiting the bootloader....(the bootloader tries to reset the trim to ''reset'' value, and writes ''0'' to the register, whereas 0x10 is the actual reset value of the trim register.)

[Tesla DeLorean]

Posted on February 20, 2016 at 21:02

That's probably less of an issue with USB/CAN where the use of HSI is generally frowned upon.

It might make sense to get the trim handled in the SystemInit() call tree, as being pulled off to 7.2 MHz might come as rather a surprise, at the very least check if it has been zero'd and apply the default.

[re.wolff9]

Posted on February 21, 2016 at 15:04The modern CPUs like the 'F072 do USB without external crystal. They trim using information from the host. I expect this to work on other modern CPUs like the L152 too. But I haven't checked.... In my case the trimming messed up UART communications.....