2020-08-21 05:22 PM
I have few devices With STM32F0xx which are connected via usb to linux hosts. In order to get necessary functionality I have to swap their firmware. Given that they are connected to linux I used first ‘dfu-util’. While tool itself completes process devices are stuck in DFU mode. Flashing process reports no issues, devices after restart report invalid firmware.
The same firmware can be updated from Windows STM Programmer. I downloaded STM Programmer for linux to check update with official tool. Result are same as for dfu-util - update doesnt work.
Issue is quite annoying cause I have no ways to determine what went wrong on STM side. All I have is USB connection and dfu mode.
Below is command I used to execute update:
/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer.sh -c port=USB1 -e 0 -d ~/Downloads/uccb/0303.hex 0x08000000 -vb 3 -rst
Firmware I am testing is open source, it is available online:
https://github.com/UsbCANConverter-UCCbasic/UCCBEmbedded/releases
https://github.com/UsbCANConverter-UCCbasic/UCCB_GS_Embedded/releases
Same thing happens when I flash https://github.com/UsbCANConverter-UCCbasic/UCCB_GS_Embedded/releases/download/0002/UCCB_GS_0002.bin
or
https://github.com/UsbCANConverter-UCCbasic/UCCBEmbedded/releases/download/4.1/0401.hex
These firmware images works properly when flashing from STM Programmer for Windows, but do not from STM Programmer for Linux.
Please let me know if my command is wrong, needs additional switches. It would be helpful is someone more experienced could say what is possible cause for failure and how to avoid it.
So far to me it looks more like tooling issue, especially that official tool behave differently on different operating systems.
Best,
�?ukasz
2020-08-22 05:37 AM
When it fails, connect and download the firmware and compare to the correct firmware to see what is different. Might shed some light on the specific problem.
2020-08-23 01:23 PM
I used both dfu-util and STM32 programmer under windows to fetch firmware from device. I noticed some differences, however I am not sure if differences are expected there.
Example output:
# read from cube under windows
bb14196af11348a36765b184420ea4fc /Documents and Settings/lukas/Downloads/dfu-master-firmware.bin
# read from dfu-util with -U switch:
~/p/dfu-util (master=) $ md5sum uccb/*UCCB_GS_0002.bin
6f671b9fca42fe68c14510e64bf47bf2 uccb/broken2_UCCB_GS_0002.bin
6f671b9fca42fe68c14510e64bf47bf2 uccb/broken_UCCB_GS_0002.bin
6f671b9fca42fe68c14510e64bf47bf2 uccb/good2_UCCB_GS_0002.bin
6f671b9fca42fe68c14510e64bf47bf2 uccb/good_UCCB_GS_0002.bin
048faa4cd85037d332df839c518617c3 uccb/UCCB_GS_0002.bin (source file)
To make matter more interesting - I tested `dfu-util` on two different hosts. Flashing process from my laptop goes quickly and succeeds to update firmware while my desktop machine always fails. I can see that there are more poll attempts on second device and sometimes process do not emit debug statements looking like it would hang. The end result of process from desktop is failed update.
I used dfu-util 0.9 as well as latest version built locally - it doesn't change much. Additional puzzle are checksums which are same for working and broken flash cycles.