When programming a virgin STM32L4 MCU through dfu-util 0.9, it won't exit dfu mode until power cycle.

[BNage.2]

I am working on a IoT product with the STM32L412CBU6 that requires flashing and testing at our manufacturer. I am able to program the device through DFU mode over USB using:

sudo dfu-util -a 0 -i 0 -s 0x08000000:mass-erase:force:leave -R -D firmware.bin

However, it does not enter back into regular mode. Even if I return the boot pin to low and reset, it still appears as a DFU device with lsusb. However, when I power cycle the device it behaves as if it has the new firmware, and I am able to update the firmware with the exact same script and set it to normal/DFU mode using the boot pin and reset.

My question is why does the dfu update work in EVERY other instance other than the very first time I flash the firmware?

[Bob S]

Probably this http://www.efton.sk/STM32/gotcha/g44.html documented by @Community member​  :)

[BNage.2]

Thanks for the insight. I am going to look into programming the option bytes. It looks like dfu-util has this as an option.

[waclawek.jan]

If this is problem, maybe the way out is through playing with the Option bytes.

Maybe inspiration:

https://community.st.com/s/question/0D53W00001NuQ1USAV/stm32g0b0-prevent-bootloader-execution-after-rdp-regression-from-level-1-to-0-and-obl-causing-mass-erase-and-system-reset

JW

[MM..1]

Why dfutil? STM32Programmer is better for this. And DFU protocol have command for run application , maybe this jump to app work.?

[BNage.2]

I have to use the DFU protocol because that is the interface we selected in product development for updating firmware. I will investigate if the STM32Programmer can run on arm through the USB.

[MM..1]

 -------------------------------------------------------------------
 STM32CubeProgrammer v2.7.0-RC1
 -------------------------------------------------------------------
 
 
Usage :
STM32_Programmer_CLI.exe [command_1] [Arguments_1][[command_2] [Arguments_2]...]
 
 
Generic commands:
 
 -?, -h, --help : Show this help
 -c, --connect : Establish connection to the device
 <port=<PortName> : Interface identifier. ex COM1, /dev/ttyS0, usb1,
 JTAG, SWD...)
 USB port optional parameters:
 [sn=<serialNumber>] : Serial number of the usb dfu
 [PID=<Product ID>] : Product ID. ex: 0xA38F, etc, default 0xDF11
 [VID=<Vendor ID>] : Vendor ID. ex: 0x0389, etc, default x0483
 UART port optional parameters:
 [br=<baudrate>] : Baudrate. ex: 115200, 9600, etc, default 115200
 [P=<parity>] : Parity bit, value in {NONE,ODD,EVEN}, default EVEN
 [db=<data_bits>] : Data bit, value in {6, 7, 8} ..., default 8
 [sb=<stop_bits>] : Stop bit, value in {1, 1.5, 2} ..., default 1
 [fc=<flowControl>] : Flow control
 Value in {OFF,Hardware,Software} ..., default OFF
 Not supported for STM32MP
 [noinit=noinit_bit]: Set No Init bits, value in {0,1} ..., default 0
 [console] : Enter UART console mode
 JTAG/SWD debug port optional parameters:
 [freq=<frequency>] : Frequency in KHz. Default frequencies:
 4000 SWD 9000 JTAG with STLINKv2
 24000 SWD 21333 with STLINKv3
 [index=<index>] : Index of the debug probe. default index 0
 [sn=<serialNumber>]: Serial Number of the debug probe
 [ap=<accessPort>] : Access Port index to connect to. default ap 0
 [mode=<mode>] : Connection mode. Value in {UR/HOTPLUG/NORMAL/POWERDOWN
}
 default mode: NORMAL
 [reset=<mode>] : Reset modes: SWrst/HWrst/Crst. Default mode: SWrst
 Reset mode with UR connection mode is HWrst
 [shared] : Enable shared mode allowing connection of two or more
 instances of STM32CubeProgrammer or other debugger
 to the same ST-LINK probe.
 [tcpport=<Port>] : Port used for running ST-Link Server, default 7184
 SPI port optional parameters:
 [br=<baudrate>] : Baudrate.

1. STM32_Programmer_CLI.exe -c port=usb1 -g