Giga DFU issues

jim.pomeroy · August 3, 2024, 6:52am

I have been trying to get my Giga arduino board to load from PlatformIO (on VS Code) all night. I have the “No DFU” problem, and cannot find a resolution.

I have Arduino IDE installed and it works fine.
I have tried “reloading” the bootloader on the Giga, using STLINK, and it doesn’t help.
I have tried putting the board in reset mode (double press RST button, pulsing LED), doesn’t help.

I’ve tried everything I can find in the community post, but I still get this:

Configuring upload protocol…
AVAILABLE: cmsis-dap, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = dfu
Looking for upload port…
Auto-detected: COM3
Forcing reset using 1200bps open/close on port COM3
Waiting for the new upload port…
Uploading .pio\build\giga_r1_m7\firmware.bin
dfu-util 0.11-arduino4

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

No DFU capable USB device available
*** [upload] Error 74

The board resets during the upload process, so it’s clear that through the the process there is some interaction with the board. Just no update.

I would be interested in ANY ideas. I’d really like to move away from Arduino IDE, but this is my first attempt at PlatformIO and it’s almost give up time for me…

Thank you.

maxgerhardt · August 3, 2024, 11:07am

Wha is your platformio.ini? Giga support was recently merged into mainline with platform = ststm32@17.5.0.

jim.pomeroy · August 3, 2024, 3:04pm

My platform.ini:

[env:giga_r1_m7]
platform = ststm32
board = giga_r1_m7
framework = arduino

PlatformIO versions
Core 6.1.15
Home 3.4.4

I updated the platform to “ststm32@17.5.0”, same result.

This certainly seems like a dfu tool issue, but I’m not sure how to resolve it.

maxgerhardt · August 3, 2024, 3:06pm

Then what’s the output of

pio run -t upload -v

on the PlatformIO Core CLI?

jim.pomeroy · August 3, 2024, 3:08pm

PS D:\PlatformIO\Barn Thermostat m7> pio run -t upload -v
Processing giga_r1_m7 (platform: ststm32@17.5.0; board: giga_r1_m7; framework: arduino; lib_deps: arduino-libraries/Arduino_GigaDisplayTouch@^1.0.1, adafruit/Adafruit Unified Sensor@^1.1.14)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: 
####://docs.platformio.org/page/boards/ststm32/giga_r1_m7.html
PLATFORM: ST STM32 (17.5.0) > Arduino Giga R1 (M7 core)
HARDWARE: STM32H747XIH6 480MHz, 511.35KB RAM, 768KB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-arduino-mbed @ 4.1.5
 - tool-dfuutil-arduino @ 1.11.0
 - tool-openocd @ 3.1200.0 (12.0)
 - tool-stm32duino @ 1.0.2
 - toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 44 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Arduino_GigaDisplayTouch @ 1.0.1 (License: Unknown, Path: D:\PlatformIO\Barn Thermostat m7\.pio\libdeps\giga_r1_m7\Arduino_GigaDisplayTouch)
|   |-- Wire (License: Unknown, Path: C:\Users\jimpo\.platformio\packages\framework-arduino-mbed\libraries\Wire)
|-- Adafruit Unified Sensor @ 1.1.14 (License: Unknown, Path: D:\PlatformIO\Barn Thermostat m7\.pio\libdeps\giga_r1_m7\Adafruit Unified Sensor)
Building in release mode
MethodWrapper(["checkprogsize"], [".pio\build\giga_r1_m7\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   9.7% (used 50696 bytes from 523624 bytes)
Flash: [=         ]  13.9% (used 109096 bytes from 786432 bytes)
.pio\build\giga_r1_m7\firmware.elf  :

section              size        addr

.text              104968   134479872

.ARM.extab            788   134584840

.ARM.exidx           1480   134585628
.data                2648   603979776
.uninitialized          8   603982424
.bss                48048   603982432
.openamp_section        0   939524096
.pdm_section        64512   939524096
.heap              472560   604030480
.lwip_sec          278528   805306368
.ARM.attributes        44           0
.comment              202           0
.debug_frame         6868           0
.stab                  60           0
.stabstr              118           0

Total              980832
<lambda>(["upload"], [".pio\build\giga_r1_m7\firmware.bin"])
AVAILABLE: cmsis-dap, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = dfu
BeforeUpload(["upload"], [".pio\build\giga_r1_m7\firmware.bin"])
Auto-detected: COM4
"C:\Users\jimpo\.platformio\packages\tool-dfuutil-arduino\dfu-util" -d 0x2341:0x0366,0x2341:0x0266,0x2341:0x0466 -a 0 -s 0x08040000:leave -D "D:\PlatformIO\Barn Thermostat m7\.pio\build\giga_r1_m7\firmware.bin"
dfu-util 0.11-arduino4

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

No DFU capable USB device available
*** [upload] Error 74

maxgerhardt · August 3, 2024, 3:18pm

And the upload still works fine in the Arduino IDE?

I do see some differences between the Arduino IDE and PlatformIO upload, in the Arduino it uses

“C:\Users\Max\AppData\Local\Arduino15\packages\arduino\tools\dfu-util\0.10.0-arduino1/dfu-util” --device 0x2341:0x0366 -D “[…]firmware.bin” -a0 --dfuse-address=0x08040000:leave
dfu-util 0.10-dev

But on PlatformIO

“C:\Users\jimpo.platformio\packages\tool-dfuutil-arduino\dfu-util” -d 0x2341:0x0366,0x2341:0x0266,0x2341:0x0466 -a 0 -s 0x08040000:leave -D “[…]firmware.bin”
dfu-util 0.11-arduino4

While some flag values are equivalent, the Arduino IDE uses a slightly older version of dfu-util.

I would advise:

Check that upload still works in the Arduino IDE. (Pointless otherwise)
In the Arduino IDE, activate File → Prefrences → Show verbose output during “upload”
Upload again. You should get a command string like above.
Copy over C:\Users\<user>\AppData\Local\Arduino15\packages\arduino\tools\dfu-util\0.10.0-arduino1/dfu-util (or whatever path it showed) into C:\Users\jimpo.platformio\packages\tool-dfuutil-arduino\ to replace the dfu-util binary.
Retry uploading in PlatformIO.

jim.pomeroy · August 3, 2024, 3:41pm

Verified the upload with ArduinoIDE still worked.

Other than the addition of new warnings about a suffix… the replacement of the dfu-util file did not work.



Processing giga_r1_m7 (platform: ststm32@17.5.0; board: giga_r1_m7; framework: arduino)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: ####://docs.platformio.org/page/boards/ststm32/giga_r1_m7.html
PLATFORM: ST STM32 (17.5.0) > Arduino Giga R1 (M7 core)
HARDWARE: STM32H747XIH6 480MHz, 511.35KB RAM, 768KB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-arduino-mbed @ 4.1.5
 - tool-dfuutil-arduino @ 1.11.0
 - tool-openocd @ 3.1200.0 (12.0)
 - tool-stm32duino @ 1.0.2
 - toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 44 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Arduino_GigaDisplayTouch @ 1.0.1
|-- Adafruit Unified Sensor @ 1.1.14
Building in release mode
Checking size .pio\build\giga_r1_m7\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   9.7% (used 50696 bytes from 523624 bytes)
Flash: [=         ]  13.9% (used 109096 bytes from 786432 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = dfu
Looking for upload port...
Auto-detected: COM3
Uploading .pio\build\giga_r1_m7\firmware.bin
dfu-util 0.10-dev

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
No DFU capable USB device available
*** [upload] Error 74

jim.pomeroy · August 3, 2024, 3:45pm

Interesting point… when I try to run the exact same command line from the ArduinoIDE output on a command prompt, I get the same “no DFU” found message.

Somehow when the command is run the in the IDE environment it can connect to the board. But outside that environment, it does not.

jim.pomeroy · August 3, 2024, 3:51pm

One other interesting note… on the Arduino output it show the upload port as COM4

*Performing 1200-bps touch reset on serial port COM3* *Waiting for upload port...* *Upload port found on COM4*

The device is on COM3. The app that I’m using just to test the upload is a simple touchscreen app that sends the location of the touch to the serial port.

I can monitor COM3 and see the output, but the upload from ArduinoIDE is COM4.

maxgerhardt · August 3, 2024, 4:17pm

It is correct that bootloader / DFU mode is only entered when opening the serial port at 1200bps shortly before upload. However, PlatformIO is also instructed to do that.

github.com

platformio/platform-ststm32/blob/075013b99c934473e1509703c6470c8bb204e999/boards/giga_r1_m7.json#L53-L53


      
          "use_1200bps_touch": true,

github.com

platformio/platform-ststm32/blob/075013b99c934473e1509703c6470c8bb204e999/builder/main.py#L232-L237


      
          if "arduino" in frameworks:
              if env.subst("$BOARD").startswith(("portenta", "opta", "nicla", "giga")):
                  upload_actions.insert(
                      0,
                      env.VerboseAction(BeforeUpload, "Looking for upload port...")
                  )

github.com

platformio/platform-ststm32/blob/075013b99c934473e1509703c6470c8bb204e999/builder/main.py#L38-L39


      
          if bool(upload_options.get("use_1200bps_touch", False)):
              env.TouchSerialPort("$UPLOAD_PORT", 1200)

github.com

platformio/platformio-core/blob/eeb5ac456eff19a8f1e2bb46397ce486be7d2a72/platformio/builder/tools/pioupload.py#L43-L51


      
          def TouchSerialPort(env, port, baudrate):
              port = env.subst(port)
              print("Forcing reset using %dbps open/close on port %s" % (baudrate, port))
              try:
                  s = Serial(port=port, baudrate=baudrate)
                  s.setDTR(False)
                  s.close()
              except:  # pylint: disable=bare-except
                  pass

It also did so in your original log

But it does not do that in that log…

Does that always happen?

jim.pomeroy · August 3, 2024, 4:28pm

Max - first… thank you for your help today! It’s really been great!

Yes, the bootloaders always.

But I think I’m getting closer to the problem… which seems to be the differences in the command lines.

PlatformIO.uses the following dfu-util switch:
-d 0x2341:0x0366,0x2341:0x0266,0x2341:0x0466

This switch identifies the device, and the device I have is the first one: 0x2341:0x0366
For some reason, identifying 3 devices in the line causes dfu-util to NOT find the device.

But if I put the board in boot mode (double press RST button), and go to the CLI line using the same command but remove the last 2 devices in the -d description… it works.

So I seem to have an answer… but how can I tell PlatformIO to ONLY call out the 0x2341 device?

Looking at the device tab in PlatformIO, it correctly identifies the device:
USB VID:PID=2341:0266 SER=003E00393033510734323437

But for some reason, it wants to try and include the other two devices.

maxgerhardt · August 3, 2024, 4:49pm

Interesting that some (?) dfu-util versions can’t handle the multiple -d switches. Especially if the right one is already the first one.

The code constructs this command from the data in the board file:

github.com

platformio/platform-ststm32/blob/075013b99c934473e1509703c6470c8bb204e999/builder/main.py#L224-L228


      
          _upload_flags = [
              "-d", ",".join(["%s:%s" % (hwid[0], hwid[1]) for hwid in hwids]),
              "-a", "0", "-s",
              "%s:leave" % board.get("upload.offset_address", "0x08000000"), "-D"
          ]

So all hardware IDs are concatinated into this list.

github.com

platformio/platform-ststm32/blob/075013b99c934473e1509703c6470c8bb204e999/boards/giga_r1_m7.json#L14-L27

So you could find the file locally (C:\Users\<user>\.platformio\platforms\ststm32\boards\giga_r1_m7.json and replace that hwids section with just

    "hwids": [
      [
          "0x2341",
          "0x0366"
      ]
    ]

jim.pomeroy · August 3, 2024, 7:05pm

All set, everything is working like normal now.

It’s odd that just the addition of those extra board possibilities caused the dfu-util to not find the present board.

local .json file updated, and everything builds and uploads properly.

Thank you again Max, learned a lot about managing the dfu commands!

maxgerhardt · August 3, 2024, 8:06pm

In any case, not being able to upload properly to the Giga without local modifications is unacceptable and a bug. Can you file one in https://github.com/platformio/platform-ststm32/issues/?

storskegg · November 8, 2024, 11:20pm

So, I’m running through this problem. In my debugging, I noticed something that I didn’t see mention above (or missed it)…

DFU Mode HWID: 2341:0366
Default Mode HWID: 2341:0266

I’m wondering if the device switch that occurs when the device (successfully) switches to DFU mode causes an interruption with dfu-util.

Anyways, just wanted to contribute $0.02 in case the extra info helps anyone.

dxbang · November 25, 2024, 12:10am

Thanks, that made it work for me too!

jim.pomeroy · November 25, 2024, 3:40am

I now have a new issue and wanted to add to this thread for others that may be having issues.

When I attempt to upload to my GIGA board when it’s running existing code, everything works fine.
But if I put the board in DFU mode (which is needed when a code issue causes the board to fail and blink the red light) it will not upload properly.

I reset the board by pressing the RST button twice, putting it in DFU mode.
When I try to upload, I get the following error:
…
Auto-detected: COM5
*** [upload] Cannot configure port, something went wrong. Original message: PermissionError(13, ‘A device attached to the system is not functioning.’, None, 31)

If I then load good code to the board (like an example sketch using Arduino IDE, which works fine), then attempt to upload again from VS Code while the good code is running, I get:
…
Auto-detected: COM4
Forcing reset using 1200bps open/close on port COM4
Waiting for the new upload port…
Uploading .pio\build\giga_r1_m7\firmware.bin
…

This works fine.

If I put the board back in DFYU mode, the Arduino IDE shows me this:
…
Performing 1200-bps touch reset on serial port COM4
Waiting for upload port…
Upload port found on COM5
…

Any ideas on why the VS code upload process doesn’t properly “touch reset” ?
Both processes are using dfu-util 0.10-dev.