AnsweredAssumed Answered

DFUSE Demo bricks STM32L476

Question asked by Seb on Oct 21, 2016
Latest reply on Oct 21, 2016 by Seb
We had success updating our device with the DFUSE demo which uses a STM32F4 device. We now have a product with a STM32L476 device, but when I try to update it via DFUSE demo, it bricks it.

To get the device in DFU mode, I do the following instructions immediately after a reset. This is similar to the STM32F4 code, but modified for the STM32L476, which has same registers but different address and bitmapping.

asm(
    "LDR     R0, =0x40021060\n\t" /* RCC_APB2ENR */
    "LDR     R1, =0x00000001\n\t" /* ENABLE SYSCFG CLOCK */
    "STR     R1, [R0, #0]\n\t"
    "LDR     R0, =0x40010000\n\t" /* SYSCFG_MEMRMP */
    "LDR     R1, =0x00000001\n\t" /* MAP ROM AT ZERO */
    "STR     R1, [R0, #0]\n\t"
    "LDR     R0, =0x1FFF0000\n\t" /* ROM BASE */
    "LDR     SP,[R0, #0]\n\t"     /* SP @ +0 */
    "LDR     R0,[R0, #4]\n\t"     /* PC @ +4 */
    "BX      R0"
);

This seems to work fine, the device enters DFU mode, and I can connect to it via USB on the DFUSe demo app. The product has a 32.768kHz LSE crystal, so the bootloader code should be running off that.

I create a DFU file using the Dfu file manager and a hex file compiled via a GCC compiler. This hex file works fine when loading the code via ST-Link utility. When I try to do an upgrade, the process looks normal (does the erase phase then the download phase). When I leave DFU mode, the device is bricked. It's consuming the same current as if it was totally erased. I need to reload the firmware via ST-Link to get it working again.

On a maybe related note, another strange behavior I'm seeing with the STM32L476, when I use my debugger via OpenOCD, everytime I start a new session I need to first erase the device via the ST-Link utility app, otherwise when code already exists, the debug session ends up in a hard fault during static initialization (I think the first malloc call).  When this happens, the device is also bricked.

Seem to me like something is getting erased during a full chip erase which is not during a new debug session or DFU USB upgrade. Something that is persistent and not being touched by a new debug session or the DFU upgrade?

Outcomes