Electronics > Repair

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

(1/4) > >>

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.

Navigation

[0] Message Index

[#] Next page