I am trying to program the STM32H753 flash on our board in DFU mode. Specifically on a raspberry pi running linux.
I connect the boot0 to 1.8V while plugging in my USB-C cable and then the boot0 jumper wires are no longer connected. So if DFU mode is exited, I expect the application to run and for blinky leds to reflect that.
In Windows, using DeFuSeDemo, I can program the flash and then click the button "Leave DFU" and see that the application was started based on LEDs that blink.
However, I can't seem to figure out the right application and syntax to program the flash from the command line with the option to leave DFU after. I'm starting to think this isn't a syntax/application issue, but maybe a board/firmware issue.
In windows, the DfuSeCommand.exe doesn't appear to have that as an option, so I can program, but stays in DFU and/or fails to start the application:
>"c:\Program Files (x86)\STMicroelectronics\Software\DfuSe v3.0.6\Bin\DfuSeCommand.exe" -c -d --v --o --fn test.dfu
1 Device(s) found :
Device [1]: STM Device in DFU Mode, having [2] alternate targets
Target 00: Upgrading - Download Phase (100)...Duration: 00:00:06
Upgrade successful !
Target 00: Uploading (100)...
Verify successful !
Using pydfu.py from the openmv project, the output indicates I'm exiting DFU, but doesn't appear to (based on no blinky leds to indicate application started).
$ python pydfu.py -u test.bin
Writing binary...
0x0800dec0 57024 [=========================] 100%
Exiting DFU...
Using dfu-util from sourceforge (tried release 0.9 and the latest unreleased from repo), I get error "can't detach":
$ dfu-util -a 0 -D test.dfu -e
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
dfu-util: can't detach
I tried a patched version of dfu-util that adds a -L command to allow STM32's to leave without needing to up/download, but unable to get success:
pi@pi-tester-1:~ $ /usr/local/bin/dfu-util -L
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
Leaving DFU mode
dfu-util: Error during leave DFU get_status
In windows, STM32 Cube programmer, when I download the firmware with the option "Run after programming", it doesn't leave DFU and run the application like I am expecting, and specifically has an error failing to start.
20:35:47 : Memory Programming ...
20:35:47 : Opening and parsing file: stm32h753-bga176-cube.elf
20:35:48 : File : stm32h753-bga176-cube.elf
20:35:48 : Size : 57024 Bytes
20:35:48 : Address : 0x08000000
20:35:48 : Erasing memory corresponding to segment 0:
20:35:48 : Erasing internal memory sector 0
20:35:49 : Download in Progress:
20:35:49 : File download complete
20:35:49 : Time elapsed during download operation: 00:00:01.411
20:35:49 : Verifying ...
20:35:49 : Read progress:
20:35:49 : Download verified successfully
20:35:49 : RUNNING Program ...
20:35:49 : Address: : 0x08000000
20:35:49 : Error: Start operation failed
20:35:49 : Warning: Connection to device 0x450 is lost
At the moment, I'm on Windows and DfuSeDemo.exe no longer detects the MCU in DFU mode, despite Device Manager showing it in DFU mode, and STM32 Cube Programmer can see it and talk to it. If I switch the cables to my linux laptop, it detects DFU mode... I'm going to guess that CubeProgrammer is keeping some handle open that it shouldn't, so I'm expecting DFuSe to work again after a PC reboot. The problem where DFuSeDemo doesn't detect it in DFU mode only started after I ran CubeProgrammer. (Edit: I found other threads talking about how the Windows driver is different for DFuSe and CubeProgrammer and so I need to revert the DFU driver on my windows box).
What could the problem be that I can leave DFU mode from DFuSeDemo but not from command line utilities? Could that be related to this FAQ about the crystal?
Our crystal (CX2016DB16000D0WZRC1) being used is 16MHz ±25ppm Crystal 8pF.
Thanks in advance for any advice or help.
