Help me repair my expensive Virpil flight sim controller (ATMEGA32U4)

[loiphin]

Hi guys,

Today is the day I ask you all for help. I have been on eevblog for many years now, and now I have a challenge.

I bought a Virpil Control Panel 2 which I use for flight sims. Cost about 300 euro, so its not cheap. Worked great for two months but now it doesn't come up as a USB device anymore at all. It just stopped working. It has sat statically in my simpit for two months. Virpil will send me a new board, but its going to take weeks, so I would like to give it a shot of fixing it myself.

Its a really simple ATMEGA32U4, running at 16Mhz. Not much on the board. Pictures below


I have the following:

* A hacked Rigol oscilloscope
* A Multimeter
* Soldering and desoldering tools
* A passion for troubleshooting (network engineer (CCIE) by trade)
* I know my way around Arduinos fairly well



What I already know:

The board doesnt boot at all. No USB indications or sounds in Windows. (I have the USB VID/PID if necessary)
I have tried the bootloader (short out the BOOT pins), but also nothing.
The only indication I have is that upon connecting the USB cable, some of the LEDs briefly flicker. Thats it.
I have managed to flash a hex image (LUFA MMJOY2 file) and successfully verified it with avrdude, using the SPI interface and an Arduino ISP. But it still shows no signs of life upon connecting. Could it be a passive component failure?
Cabling is verified good.


I have no experience on where to start troubleshooting. Obiwan, you are my only hope....

I have the binary hex image for the Virpil controller, from their VPC Configuration tool (this tool allows you to configure the joystick and do custom things). The problem is that the image doesnt appear to be in standard Intel hex. It has a .HEXC extension, so I wonder if they have compressed it? Maybe someone could figure it out.


Thanks in advance to all those who wish to give me some basic troubleshooting methodologies. It would be immensely satisfying to fix this.


loiphin.

[T3sl4co1l]

Huh, how does anything connect to that, all those headers are really unused?

Could very well be the USB PHY stuff got zapped.  If that header is straight up to the USB port, there's no ESD protection on there so who knows.  Fairly uncommon I'd want to say, what with the shield there, USB has a fair amount of immunity just from ESD striking the shield instead of the signals -- but a poorly constructed header (or a header at all, versus a grounded metal enclosure) might not be well enough shielded, and ESD gets into the signals that way.

So you have direct programming access, that's great.  Wonder if anyone has a diagnostic program, run through the peripherals, check behavior sort of thing?  Assumes some kind of IO to see it working, maybe as simple as a go/no-go LED, preferably a serial console or something.  Probably easy enough to grab two or three of those (unused?) pins and hook up the USART for that.  Do you have a TTL/logic level serial adapter?

Depending on if such exists, or how ready-to-go it is, this is getting more into programming / embedded development though.  So you'd need a tool chain, C source (or whatever), and preferably an IDE.  All of which are readily available, and fairly easy to use considering; but would be a lot more faffing about than you might've been looking for.  On the upside, it's one way to introduce yourself to "bare metal" AVR, or really, you could use Arduino on that just as well (if there's library support for that particular device).

Tim

[loiphin]

The 2mm pins on the Atmel side connect to another subboard, which has all the LEDs, switches etc. So there are probably some multiplexed buttons I guess.

Yes, I have a bunch of serial console stuff lying around, CH340, Fake FTDI232s etc. So I could hook up to the serial port.

Is it unlikely the resistors or caps are dead? And the crystal? Can we assume the crystal works because I could flash the atmega32u4 via SPI?

I had a quick look under the microscope and it has a bunch of WS2811 chips to drive the colour LEDs, and a single ATTINY88. These are on the other sub-boards on the controller. So I wouldnt worry about them for now, because the atmega32u4 is the main problem.

[Venturi962]

A few things to check on the hardware side.  ATMega32U4 requires a 1uF Cap on Pin 6 for USB, check the connections and that the cap isn't shorted.  Probably good to check the connection to the white header on the opposite side for the USB Data Pins (Pins 3,4) - should measure 22 Ohms from the MCU to the pin.

[loiphin]

I can confirm 1.1uF cap on Pin 6, and USB data pins each have a 22 Ohm resistor.

[T3sl4co1l]

I forget what all the chip needs to program; SPI is synchronous so it might not need anything at all.  If it weren't, basically, the concern would be, you could brick it by burning all the clock-select fuses I think.  Which would be kind of silly.  (Or maybe not, I forget what all options are on the fuses.)  If nothing else, the internal RC timer can keep it going; though I don't know if they ever actually use it for housekeeping functions or what have you.  (Later models e.g. XMEGA, AVR-Dx, etc. make prominent use of internal clocks, which are greatly improved, accurate enough for most applications -- no crystal needed for serial at least, and I think maybe even the USB ones either manage as-is, or do clock recovery? I forget.)

Ahh so it's all going through serial, interesting.  Which basically means, this chip is a USB to serial (WS2811 and, whatever the ATTINY is talking, USART? SPI?) bridge of sorts; and probably the ATTINY itself is another serial bridge to IO expanders or something, or maybe it has enough inputs by itself to read all the controls.  Kind of a weird choice with so many pins handy on this board, but it probably makes sense based on other products they've made; evolution is weird like that.

Crystal, you can probe with the scope; it'll probably handle that.  The scope probe (use a 10x probe) will load it down a bit, but one of those pins probably still has enough to see on it.  The amplitude is usually pretty modest (fractional volt) -- as long as there's anything at all, it's working fine.

A few things to check on the hardware side.  ATMega32U4 requires a 1uF Cap on Pin 6 for USB, check the connections and that the cap isn't shorted.  Probably good to check the connection to the white header on the opposite side for the USB Data Pins (Pins 3,4) - should measure 22 Ohms from the MCU to the pin.

Yep basically this, there's not much to the USB side of things.

Tim

[Venturi962]

You could try flashing the Arduino Leonardo Bootloader (which uses a 16MHz crystal) via the ISP and then seeing if the chip will enumerate over the USB header.  You can cut up a USB cable to connect to the board.

[loiphin]

You could try flashing the Arduino Leonardo Bootloader (which uses a 16MHz crystal) via the ISP and then seeing if the chip will enumerate over the USB header.  You can cut up a USB cable to connect to the board.

Yeah, that was the first thing I tried. It didnt show any signs of life. I can try again to be sure.

[loiphin]

Crystal, you can probe with the scope; it'll probably handle that.  The scope probe (use a 10x probe) will load it down a bit, but one of those pins probably still has enough to see on it.  The amplitude is usually pretty modest (fractional volt) -- as long as there's anything at all, it's working fine.

I can see 16Mhz on the crystal with my scope. Nice and clear sine wave

[Venturi962]

You can check the Reset line - Pin 13, should be high.  If that's alright, I imagine the USB block is bad.

[ozcar]

You could try flashing the Arduino Leonardo Bootloader (which uses a 16MHz crystal) via the ISP and then seeing if the chip will enumerate over the USB header.  You can cut up a USB cable to connect to the board.

Yeah, that was the first thing I tried. It didnt show any signs of life. I can try again to be sure.

How do you restore the original code after doing that? If they provide some tool to load the HEXC file (whatever that is), then replacing the ATMEGA32U4 could be an option.

[FireHazard]

Crystal, you can probe with the scope; it'll probably handle that.  The scope probe (use a 10x probe) will load it down a bit, but one of those pins probably still has enough to see on it.  The amplitude is usually pretty modest (fractional volt) -- as long as there's anything at all, it's working fine.

I can see 16Mhz on the crystal with my scope. Nice and clear sine wave

Can somebody explain the danger of probing this please? I pretty much stick my scope on anything without regard having assumed the high impedance would keep everything safe...I have much to learn here.

As a newbie here the stuff in this thread is gold...why can't there be a book or a guide with this!! Would pay.

[T3sl4co1l]

The crystal node is fairly high impedance (a few kohms at 16MHz, up to 100s of kohms for 32kHz crystals).  The oscillator is usually implemented with a transconductance amplifier inside the device, with a small loop gain margin, hence the low signal level, and the added loading from the probe can be enough to quench oscillation.

Especially so for weak / somewhat notorious parts, like, STM likes to use fairly weak oscillators in their MCUs, needing high-ESR crystals as a result.  So they're particularly hard to probe.

A probe is NOT an ideal sensor, and is not even the ideal 10M || some pF that they are usually labeled as.  In fact, that capacitance has substantial ESR, so that at high frequencies, the probe approaches a "low Z" (i.e., 450R probe "tip" in series with 50R terminated cable) characteristic instead.  For inbetween frequencies (say 10kHz-10MHz), there's intermediate levels of ESR.  So, that acts to dampen the node being measured.  Not a problem for digital signals (<100 ohms source impedance), or power circuits (~ohms source impedance, usually), not often a problem for analog circuits even, but anywhere high impedances are present, it's something to think about.

Tim

[loiphin]

You could try flashing the Arduino Leonardo Bootloader (which uses a 16MHz crystal) via the ISP and then seeing if the chip will enumerate over the USB header.  You can cut up a USB cable to connect to the board.

Yeah, that was the first thing I tried. It didnt show any signs of life. I can try again to be sure.

How do you restore the original code after doing that? If they provide some tool to load the HEXC file (whatever that is), then replacing the ATMEGA32U4 could be an option.

I have resigned to the fact that the ATMEGA32U4 has popped. So I have a replacement on an old Arduino board which I will desolder and move over. But I want to first flash it. The problem is that Virpil appears to use a custom HID bootloader. And I have no idea how to reverse engineer the HEXC file within their software. I assumed its compressed or encrypted with a XOR function. I have asked over on their forums if someone could provide me with the bootloader, but so far no one has answered.

[loiphin]

I received a warning from Virpil not to mess with replacing the atmega32u4, as it will void my warranty. And they wont provide the .hex bootloader. So will just have to wait for the replacement board from them.

So I guess its the end of the road for now. Perhaps I will read the flash off the replacement before installing it, to see if I can in fact fix the original.

[wraper]

I received a warning from Virpil not to mess with replacing the atmega32u4, as it will void my warranty. And they wont provide the .hex bootloader. So will just have to wait for the replacement board from them.

So I guess its the end of the road for now. Perhaps I will read the flash off the replacement before installing it, to see if I can in fact fix the original.

Do you need to return the old board? Otherwise it nonsense.

[loiphin]

I received a warning from Virpil not to mess with replacing the atmega32u4, as it will void my warranty. And they wont provide the .hex bootloader. So will just have to wait for the replacement board from them.

So I guess its the end of the road for now. Perhaps I will read the flash off the replacement before installing it, to see if I can in fact fix the original.

Do you need to return the old board? Otherwise it nonsense.

No fortunately don't need to return the old one. Virpil is based in Belarus so it makes things a bit more difficult. Although they have an EU distribution centre in Lithuania.

[ledtester]

In theory the firmware for the atmega32u4 is pretty straightforward. The 32u4 can easily implement a USB "human interface device" (HID) which encompasses joysticks, mice, switches, sliders, keyboards, etc. In fact, there is an Arduino Joystick library which can be used with the Arduino Pro Micro board (which uses the atmega32u4) which makes implementing your own game controller very easy.

Here's a video demonstrating the process:

Arduino Joystick 2.0 Library - Beginners Guide
https://youtu.be/hoCOq9Ngp44

and an Instructable:

https://www.instructables.com/Arduino-LeonardoMicro-as-Game-ControllerJoystick/


Arduino Joystick Library:
https://github.com/MHeironimus/ArduinoJoystickLibrary

So if you know how to read the various sensors on your controller you could write your own code to turn it into a USB HID device.

[loiphin]

Just a quick update:

Received my replacement board from Virpil today after a loooooong wait. All is working again. So it was the ATMEGA32U4 that was no longer working on the USB side, in the failed part.

Out of interest I tried to read the flash, eeprom and fuse bits on the new board before I installed it. Unfortunately the flash is locked and cannot be read, so was unable to download a copy to allow me to fix the broken board.


Thanks for all the help from everyone in this thead


loiphin.