Trying to add VIRPIL re-badged/re-vendored m32u4

[phillxnet]

I have a VirPil (VPC) joystick confirmed via visual chip inspection to be using a Mega32U4-MU (in my device). Virpil's own software (Windows only) looks to run under modern wine just fine except for firmware updates: but aggressively requires these, and refuses to configure before they are performed. I have no, and want no, access to windows; preferring instead to enable firmware updates within linux via AVRDUDE. But require some pointers on how to get this working ready for a PR here.

Current state is post failed (in wine using virpil software) firmware update with the following USB device now showing:

lsusb
Bus 001 Device 002: ID 3344:0002 Leaguer Microelectronics (LME) VPC-BOOT

With their software debug option displaying (5 step):

-- Write page error [1/193][General failure]

and the following in system journal on the linux wine host:

Apr 06 19:18:13 phildev env[98507]: 00cc:err:hid:hidraw_device_set_output_report id 0 write failed error: 110 Connection timed out

User in games group and udev rules are in place to enable access, i.e. /dev/hidraw0 is created with group of "games".

ls -la /dev/input/by-id/usb-VPC_VPC-BOOT_VPC-BOOT-20240814-hidraw
lrwxrwxrwx. 1 root root 13 Apr  5 19:41 /dev/input/by-id/usb-VPC_VPC-BOOT_VPC-BOOT-20240814-hidraw -> ../../hidraw0
ls -la /dev/hidraw*
crw-rw----. 1 root games 243, 0 Apr  5 19:41 /dev/hidraw0

An older [device report] 1 indicats Virpil previously did not USB re-vendor (VID) and used instead the upstream Atmel vendor ID at least for their boot-loader mode: presumably DFU.

• 03eb:2043 LUFA Joystick Demo Application

Thus far I have added, to accommodate for the 3344 vendor ID presenting currently a flip1 variant thus:

programmer # flip1
    id                     = "flip1vpc";
    desc                   = "FLIP bootloader using USB DFU v1 (doc7618)";
    type                   = "flip1";
    prog_modes             = PM_SPM;
    connection_type        = usb;
    usbvid                 = 0x3344;
;

Essentially identical bar usbvid to the existing flip1 entry in /usr/local/etc/avrdude.conf, I initially tried extending the existing flip1 entry by using the list for for usbvid but it was rejected, indicating only the first (original 0x03eb) was being used.

I have also, to accommodate the the :0002 VPC-BOOT USB PID, added a new device akin to the existing m32u4 entries.
Again I had to do a new devices as I had trouble with only the first, existing usbpid being accounted for.
N.B. I need to double check if only flip1 or this new m32u4vpc entry refused to use more than the first list entry when added.

part parent "m32u4" # m32u4 in more recent VPC devices have different usbpid and signature
    desc                   = "ATmega32U4vpc";
    id                     = "m32u4vpc";
    variants               =
        "ATmega32U4-MU:    QFN44,  Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[2.7 V, 5.5 V]";
    signature              = 0xff 0xff 0xff;
    usbpid                 = 0x0002;
;

I am running on openSUSE Tumblweed and have compiled my AVRDUDE instance using (from config file):

• avrdude_conf_version = "8.1-20260405 (e88950e)";

I intend to submit a PR on the required package names to extend the existing For RPM based systems on this when time resources allow. This was to enable the GUI and to be able to contribute if need be.

Current blocker

When selecting both the flip1vpc and the m32u4vpc in the avrdude-gui I now get the following:

Welcome to AVRDUDE!
Found avrdude.conf in /usr/local/etc
Loaded 4 settings from /home/philip/.config/avrdude/adgui.conf
Log level set to 3
Device set to ATmega32U4vpc
No configuration table found
Programmer set to flip1vpc
Port set to usb

And the command line invokation gives:

avrdude --programmer flip1vpc --part m32u4vpc signature:r:-:r 
Warning: USB bDeviceClass = 0 (expected 254)
Warning: USB bDeviceSubClass = 0 (expected 1)
Warning: bMaxPacketSize0 (8) != 32, things might go wrong
Error: unable to reset DFU state: Input/output error
Error: DFU_DNLOAD failed: Input/output error
Error: unable to get DFU status: Input/output error
Error: unable to read signature data for part ATmega32U4vpc (rc = -1)
Error: unable to read signature data (rc = -1)
use -F to override this check

From this I'm assuming my next outstanding issue re adding compatibility to avrdude for this device is the:

No configuration table found

and the numerous Warning: & Error: results from the CLI invocation to read the signature.

My apologies for reaching out when I'm obviously new to AVRDUDE but I would very much like to add compatibility for this manufacturers offerings as there is now quite the linux interest and the firmware update looks to be a show-stopper - and is likely best performed under AVRDUDE natively rather than within a deeply nested arrangement such as the Virpil Windows software under wine.

N.B. the apparent firmware file offered within the Virpil software was named:

• Firmware_vpc_20260218_[CNT-ATMEGA32U4].hexc

And I have an open forum support post with Virpil on the format as it does not look like (but maybe akin to) intel-hex. However I first need to be able to demonstrate unerrering communication with their/my-devcies Mega32U4-MU chip over USB before hand.

Thanks in advance for any pointers anyone can given on this front. I think I'm close but missing something likely obvious from another's more informed perspective. And I would also like to submit any progress made via PR once I/we have an actual working instance at least for the single device I have here. Hopefully variants can then be added as folks discover AVRDUDE as a viable Linux workaround for Virpils lack of Linux support. Or potentially as a likely more reliable means to flash/update these devcies on Windows.

[stefanrueger]

their boot-loader mode: presumably DFU

It's vital to know which bootloader is installed on the m32u4. If it's a proprietary one that VirPil rolled then AVRDUDE is unlikely to be able to deal with it unless its protocol is compatible with the standard bootloader that the m32u4 ships and that avrdude -c flip1 understands.

If it is the original bootloader or a compatible one, just re-vendored:

Your own definition of flip1vpc and m32u4vpc look good except for the signature: 0xff 0xff 0xff is defo wrong but might be something that a failed read attempt shows. I suggest removing the signature line in the part definition. If AVRDUDE isn't able to establish meaningful comms to ask and verify the signature, the quest is already lost. On a compatible bootloader I would expect the following

$ avrdude -qq -c flip1vpc -p m32u4vpc -U signature:r:-:h
0x1e,0x95,0x87

Note the -U. (Maybe someone in the team with an orginal m32u4 can verify my prediction using -c flip1 -p m32u4)

And yes, the .hexc file format is nothing AVRDUDE knows of. That would need converting into one of the supported formats first (eg, Intel Hex, Motorola S-Record, raw binary). You may be able to guess the record structure of the .hexc files and reverse engineer, though.

No configuration table found

That may be a red herring as the configuration table won't be needed for bootloading. I wonder why you got this, though. Using your part definition without the signature line AVRDUDE finds the configuration table:

$ avrdude -qq -c dryrun -p m32u4vpc -T "config lb"
config lb=no_lock # 3

[phillxnet]

@stefanrueger Thanks for help here, much appreciated.

Yes, I was rather hoping Virpil had simply re-branded (usb id changed) the default bootloader so it would still be flip1 compatible.

Your own definition of flip1vpc and m32u4vpc look good except for the signature: 0xff 0xff 0xff is defo wrong but might be something that a failed read attempt shows.

Yes, I got that signature from an earlier avrdude-gui run where it returned that as read from the device - but the logs did indicate there was an error in the reading.

I have since, inline with your suggestion, now removed the fake signature entry from the part and run your suggested command:

avrdude -qq -c flip1vpc -p m32u4vpc -U signature:r:-:h

Warning: USB bDeviceClass = 0 (expected 254)
Warning: USB bDeviceSubClass = 0 (expected 1)
Warning: bMaxPacketSize0 (8) != 32, things might go wrong
Error: unable to reset DFU state: Input/output error
Error: DFU_DNLOAD failed: Input/output error
Error: unable to get DFU status: Input/output error
Error: unable to read signature data for part ATmega32U4vpc (rc = -1)
Error: unable to read signature data (rc = -1)
use -F to override this check

Which does not look promising if I'm reading your response correctly. That would be a shame indeed.

But! I see the following, when running the above command, in the system log via sudo journalctl -f

Apr 10 16:46:46 phildev kernel: usb 1-1: usbfs: process 8115 (avrdude) did not claim interface 0 before use
Apr 10 16:46:46 phildev kernel: usb 1-1: usbfs: process 8115 (avrdude) did not claim interface 0 before use
Apr 10 16:46:46 phildev kernel: usb 1-1: usbfs: process 8115 (avrdude) did not claim interface 0 before use

Which may point to a permissions or compatibility element out-of-wack.

Re your -c dryrun on the custom part for investigating the No configuration table found I get the same output as you on my build here i.e. "config lb=no_lock # 3".

With the AVRDUDE reported "Input/output errors" (3 per above run) matching the 3 system log entries re "did not claim interface 0 before use" I'm thinking there is still hope on this front? I don't however see any new entries re SELinux via sudo tail -f /var/log/audit/audit.log!

sestatus 

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actu

Curiously, via avrdude-gui, again using the custom flip1vpc and custom part, when I do File -> Attach Programmer I see the following system entry:

Apr 10 17:07:21 phildev kernel: usb 1-1: usbfs: process 8745 (python3.13) did not claim interface 0 before use

And the following in the log window of the avrdude-gui (Loglevel debug):

Selected programmer: FLIP bootloader using USB DFU v1 (doc7618) (flip1vpc)
Selected port: usb
dfu_open("usb") 
found device with vendorID=0x3344 and productID=0x0002, busdir:devicefile = 001:009 
using VID=0x3344 PID=0x0002 at 001:009 
USB bDeviceClass = 0 (expected 254) 
USB bDeviceSubClass = 0 (expected 1) 
bMaxPacketSize0 (8) != 32, things might go wrong 
USB Vendor : VPC (0x3344) 
USB Product : VPC-BOOT (0x0002) 
USB Release : 0.0.1 
USB Serial No : VPC-BOOT-20240814 
USB max packet size : 8 
unable to reset DFU state: Input/output error 
Programmer successfully started

Device - Programming - Signature (Tab) - Read (button) - get the remaining parallel 2 errors:

Apr 10 17:13:09 phildev kernel: usb 1-1: usbfs: process 8745 (python3.13) did not claim interface 0 before use
Apr 10 17:13:09 phildev kernel: usb 1-1: usbfs: process 8745 (python3.13) did not claim interface 0 before use

avr_read_mem(, m32u4vpc, signature, NULL) 
flip1_read_sig_bytes(): from device 
DFU_DNLOAD failed: Input/output error 
unable to get DFU status: Input/output error 
Signature read from device does not match config file

Thanks again for the pointers here.

[stefanrueger]

Permissions: With your extra definitions, look at the output of

$ avrdude -c flip1/u

That should entail instructions for installing udev rules on a generic Linux (don't know about Tumbleweed).

[stefanrueger]

Errata: I meant avrdude -c flip1vpc/u, of course, but I am sure you realised that @phillxnet