USB: Remove DFU interface from Uno R4 WiFi

[mgcookson]

Change motivation summary

The Uno R4 WiFi mistakenly presents a DFU port to its host when connected via USB.

Change motivation details

When the Uno R4 WiFi is connected to a Windows host via USB cable, the Windows Device Manager app reveals that the device's DFU port is missing a driver. Attempting to install a driver via the Windows driver installer in this repository's ..\drivers folder does not resolve the issue. However, since the Uno R4 WiFi uploads applications via a COM port, not DFU, it should not be presenting a DFU port to the host at all.

Resolution summary

• Modify the Uno R4 WiFi's variant specific header file (tusb_config.h) to disable CFG_TUD_DFU_RUNTIME.
• Modify the USB descriptor setup code (in USB.cpp) to respect the CFG_TUD_DFU_RUNTIME value in the header file.

Resolution notes

I have altered how all of the USB interface descriptors are constructed to unify the approach used for each and improve the maintainability of the code. This expanded the scope of changes that were strictly required to address the issue, but I felt it made the entire method a bit easier to understand and manage going forward.

Research supporting chosen resolution

Examination of the two files noted below leads me to believe that all board variants supported by this repository support DFU except the Uno R4 WiFi.

DFU device driver installer INF (../drivers/renesas.inf)

• The PID for the Uno R4 WiFi device (0x006D) is not present in the DFU device driver installer INF file.
• The PID for all other board variants are present in the DFU device driver installer INF file, and have CFG_TUD_DFU_RUNTIME enabled in their variant specific header file.

Arduino boards definition (../boards.txt)

1. All boards use dfu-util except Uno R4 WiFi, which uses bossac.

Notes

• While I recognize that the ESP32-S3 used in the Uno R4 WiFi does in fact support DFU, I don't believe that people who are using that ability will be affected by this change. If I am incorrect on this point, let me know and I will review further.
• In addition to the Uno R4 WiFi, I also have an Uno R4 Minima. I tested its behavior with this PR - it continues to function using DFU as expected. I do not have any other devices to test with, so that is a potential gap that could be addressed prior to merging this PR.
• Pre-existing behavior when the DISABLE_USB_SERIAL macro is defined has been preserved. Specifically, when this macro is defined at compile time the device will not present either a DFU or a CDC interface to its host at runtime.
• This PR has the following effect on program memory usage for the following few devices I checked:
  • Uno R4 Minima: +168 bytes
  • Uno R4 WiFi: -200 bytes
  • Portenta C33: +208 bytes

[pennam]

Hi @mgcookson is this a windows specific issue? when i connect the uno R4 WIFI to my linux pc it not get listed as dfu device.

The PID of the UNO is 1002 not 006d, did you change it on purpose ?

[mgcookson]

@pennam Thank-you for the question. Answers:

I have not tested this on any platform other than Windows. However, since the device's USB characteristics are published to the USB host by the device itself regardless of what OS the host is running, I cannot quite see how it wouldn't present a DFU port to a Linux host as well as a Windows host.

From everything I can see, the PID of the Uno R4 WiFi is indeed 0x006D. I did not change anything. See here for existing code supporting my position:

ArduinoCore-renesas/variants/UNOWIFIR4/pins_arduino.h

Line 166 in f032b82

#define USB_PID (0x006D)

If I've missed anything I'm happy to be educated - I have no issues learning where I might have gone astray in this PR.

[pennam]

Oh I've got it ! 0x1002 is the pid of the UNO when the board is in bootloader mode. But even in bootloader mode my board does not show up as dfu peripheral.

Could you please doublecheck if loading a blink sketch on your boar the PID is changing from 1002 to 006d ?

Tomorrow i will try my board on a windows machine. Which windows version are you using?

[pennam]

Oh I've got it ! 0x1002 is the pid of the UNO when the board is in bootloader mode. But even in bootloader mode my board does not show up as dfu peripheral.

Could you please doublecheck if loading a blink sketch on your boar the PID is changing from 1002 to 006d ?

Tomorrow i will try my board on a windows machine. Which windows version are you using?

Discard this message, it is all wrong 😢

0x1002 is the default PID of the UNO R4 WiFi exposed directly by the ESP-32-S3

0x006d is the RA4M1 native pid and is exposed by the board when using a sketch from the Examples/USB folder

After loading one of those sketches my board reports the PID 0x006d and I've also found the dfu interface.

Found Runtime: [2341:006d] ver=0100, devnum=42, cfg=1, intf=2, path="1-4.1.2", alt=0, name="DFU-RT Port", serial="3213262559313236796533314B572C41"

[mgcookson]

Apologies for my delay. Thank-you, your results match my understanding of what we should be seeing with the current release of the Arduino Renesas core.

So the next question is: Is there actually any reason to have the DFU interface published by the device when running a user's sketch? It honestly isn't hurting anything, it's just potentially confusing to Windows users because it shows up in Device Manager as an error and the user has no way to fix it.

To answer one of your questions - I am running Windows 11 Pro, but I've used all prior versions of Windows and to the best of my recollection Device Manager has always highlighted ports that are missing drivers or otherwise non-functional.