LilyGo ATMEGA32U4 - not recognized from device manager

Using Arduino Microcontrollers
1

Introduction
Hi everyone,

This is my first time posting on the Arduino forum, and I hope my contribution will be helpful to others. I wanted to share my solution to a problem I encountered, along with some insights that were particularly useful to me.

I was working with the LilyGo TTGO USB ATMEGA32U4 and accidentally uploaded a sketch incorrectly using the Arduino IDE. This caused the device to become "unrecognizable" in the Windows Device Manager, showing up as "Unknown USB Device (Device Descriptor Request Failed)" or something similar.

image
image1000×1000 38.4 KB

In my case, I managed to "brick" the device by first selecting the wrong board/programmer in the Arduino IDE and then uploading a sketch. So this resemble a lot this post.
I’m writing this post to describe a final step that helped my PC recognize the microcontroller again.
The solution discussed in the post above is this one. In this post though, they doesn't show the exact same board, but others with the same ATMEGA32U4 microcontroller.

Initial situation
Initially, I was able to use the device normally after setting it up with the Arduino IDE. However, after selecting a random board/programmer and attempting to upload a sketch, the device became undetectable by the Windows Device Manager. It showed up as Unknown USB Device (Device Descriptor Request Failed) with error code 43 in the device details.

Solution
After trying various driver-related fixes in Windows to no avail, I realized that the issue was with the microcontroller's program, which was interfering with the PC's USB detection.

  • Dismantling the Microcontroller: I used a pair of pliers to extract the metal case containing the controller from the outer case. I then used a screwdriver to carefully lift the controller from the bottom to detach the adhesive tape and push it out. Be gentle to avoid damaging the board.
  • Resetting the Microcontroller: Once the controller was out, I connected it to my PC again. Then, using a wire, I shorted the ISCP pins GND and RST together to put the device in reset mode. Here’s the pinout of the board (props to the guy that mapped them).
  • Uploading the Sketch: After resetting, I opened the Arduino IDE, navigated to the "EEPROM" examples, and selected the "eeprom_clear" sketch. I shorted again the pins RESET and GND together and quickly uploaded the sketch.

image
image562×724 32.7 KB

After following these steps, my board was detected as a COM port in the Device Manager again, and everything worked fine for me.

I hope this explanation wasn't too long, and if anyone has more insights on this topic, please feel free to share your knowledge!

Outro
I am writing this post few days after the problem has been solved using this exact method, sorry if everything is not technically precise I am slightly tired writing this.
I didn't replicate the problem multiple times because I didn't want to open it again and risk to damage the board, so this is what I managed to collect.
I am not sure about the eeprom_clear sketch and why it worked when others didn't, I tried other uploads but this one did the job.

2

I use 8MHz/3.3V Pro Micros. When I just got them, I was too eager to play and uploaded a sketch using the Leonardo a Micro selection. Upload worked and after that I could no longer upload, board not recognised.

Adding a reset button and double tapping it allowed me to upload again; and obviously installing the SparkFun AVR board package and selecting the correct board and options.

The problem with boards with native USB is that part of the code contains functionality so the board can identify itself to the PCand to react on the software reset that is issued by the IDE (opening/closing the serial port with a baud rate of 1200 baud) before the the actual upload starts.

That functionality can fail if you programmed a board with the wrong clock selected (in my case 16MHz instead of 8MHz) or due to bugs in the uploaded software (usually the part that you wrote but it also can be a library).

1 Like
3

Thanks for the interesting insights! I wasn't aware of the software Reset issued by the IDE, I will look into it :slight_smile:

But yes, the board is pretty sensible about what you upload and how you upload it, like you, I was also eager to use it and managed to brick it uploading using the (definitely) wrong settings.

Do you have any opinion/idea on why the eeprom_clear sketch managed to being uploaded to the board, even when the micro wasn't detected as a COM from the device manager?

4

No idea; basically any standard sketch should upload after a doubl- tap reset.

Note that double-tap is not always needed, sometimes a single tap will invoke the bootloader; it depends on the board. You can see the reset (software as well as hardware) behaviour in e.g. Windows device manager. The normal port will disappear and a different one will show up.

Your problem is that you don't have easy access to the reset pin of the processor to perform the hardware reset. I think it is advisable to create your project using a different board (e.g. Arduino Leonardo, Arduino Micro or SparkFun Pro Micro) and transfer the project after full debugging / testing to your dedicated board; it makes accessing the bootloader a lot easier.

Note:
Not familiar with your board.