Custom PCB using atmega32u4 appearing as unknown device

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I have completely read the thread from 2017,  https://www.avrfreaks.net/forum/custom-atmega32u4-pcb-connects-windows-unknown-usb-device?skey=unknown%20usb%20device%20atmega32u4 . This thread is custom pc2, electric boogaloo.

 

I have gone through the thread and recreated (almost) all of the troubleshooting tips, this is my progress:

 

  • Both 22 ohm resistors in the D+/D- lines from the usb port are checking out at 22 ohms on the meter.
  • Drivers are installed
  • Re checked all solder joints, they look fine

 

Need help using scope to check crystal frequency, cannot seem to get a good reading. crystal is 16mhz FA 238 package

 

Does pin 33, the HWB need to be connected to ground? 

 

Is there something I'm missing? the atmega32u4 comes with a bootloader already

 

I am pretty new at all this, so any input is greatly appreciated. 

 

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Old_Gold_Hand wrote:
Does pin 33, the HWB need to be connected to ground? 
Depends on how the fuses are set. What is the state of HWBE ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Old_Gold_Hand wrote:
Is there something I'm missing?
UCAP is incomplete per the datasheet; given USB Vbus, the USB megaAVR will supply current for the USB common-mode voltage.

Most voltage regulators need a bit of capacitance for stability.

ATmega32U4 - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UCAP is incomplete per the datasheet; given USB Vbus, the USB megaAVR will supply current for the USB common-mode voltage.

 

Most voltage regulators need a bit of capacitance for stability.

 

 

I will jump in a 1uf cap next opportunity. I searched the datasheet (using ctrl+f "UCAP") and could not find any info. Buckminster Fuller's quote is inspiring because I am plunging headlong into a steep learning curve. 

 

Depends on how the fuses are set. What is the state of HWBE ?

 

I dont know how to read the state of the pin. It is how it comes from the factory.

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Is it an ATmega32U4-AU or an ATmega32U4RC-AU ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATmega32U4-AU

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Data sheet says the non-RC has HWBE programmed to 0 (active) by default. So it *will* be exercising the HWB mechanism. That means that at power on it will be sensing the state of the HWB input pin and if found low it will enter the bootloader, while if not low it will execute the app (presumably "blank"). The idea behind HWB (as opposed to BOOTRST) is that you don't want a USB chip with a USB bootloader enumerating as the bootloader device at EVERY power on (usually it goes to the app and that enumerates as some other class of USB device). The plan then is that you have a (weakly pulled up) push button on the HWB pin. If you power on and DO want it to bootload you hold the button down, HWB is pulled low, the chip senses this (because HWBE is active) and starts the bootloader.

 

So either tie the pin low (in which case you might as well have just activated BOOTRST anyway) or put a pull up/button on it and close that to Gnd if you want it to bootload at power on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


How does this differ from the reset pin? as of now when I press reset while the device is plugged in, windows bing bongs that a device is disconnected, then it reconnects after a short while as unknown device. When it reconnects, it is running the app?

 

If i move the push button to HWB pin as you described, and it bootloads at power on, does that mean the app wont run?

 

The device is a prototype input device (a macro pad), so I am guessing I do not want it to bootload at power on.

 

For reference, here is a schematic using the same MCU from a tutorial I followed a few months ago.

 

Why are one of the decoupling caps 4.7u? He has this routed to pin 7 (VBUS) on the pcb.

why does he have a 10k resistor to HWB tied to ground? does this make the device bootload upon power on?

I see he has a 1uf cap on UCAP (Facepalm).

 

Thanks for your help so far, I am digesting the info about BOOTRST as we speak.

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Old_Gold_Hand wrote:
How does this differ from the reset pin?
Sorry I thought I had explained. USB AVR have three reset strategies available

 

1) they could always just reset into the app - use this when no bootloader. Assuming USB is used the app code will immediately enumerate as the chosen USB class for the application

 

2) use BOOTRST - this assumes that on every power on the boot code runs first. It could make some early decision of it's own devising as to whether it will bootload or not. If it chooses to it will enumerate as the class for the bootloader - so probably CDC-ACM or DFU. Once bootloading is over and the app runs it will need to switch to some other USB class to suit the app. If no early decision logic is implemented it will start by enumerating the bootloader CDC/DFU first every time it powers on

 

3) use HWBE and the built in pin sensing mechanism to decide if the bootloader should run or not - as I say, with this selected it's then down to the state of HWB pin at power on. This is because you probably don't want it to start by enumerating CDC\DFU for the bootloader at every power on. So the user has to do "something special" (button held down to ground HWB) to say "do bootload, do enumerate as bootloader class first". I guess this *could* have further decision logic where the bootloader does start but does not enumerate immediately even in this case but makes some further decision (like is an EEPROM flag set or something?) before it appears as the bootloader class

 

The normal 32U4 (nonRC) comes with HWBE (3) enabled because Atmel are expecting the implementer to put a boot decision button on the HWB pin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like I am looking to utilize strategy 3. Can you tell if this is the strategy used in the second schematic I posted?

 

If this is the factor default for the 32U4, does that mean (assuming I iron out the electrical issues on the pcb) that this is the order of things that are happening:

 

I plug in my device, Windows recognizes the ATMEGA32u4, I press the reset button, The DFU bootloader runs, I flash firmware over the USB, I reset again

 

now when i power on the device (plugging it into the USB port), It enumerates (i dont know if im using this correctly) as HID (from firmware?), Windows recognizes it as an HID, and the app runs

 

Is this close to the mark?

 

I think I have electrical issues, as other people have made the pcb as per the second posted schematic and it has shown up as atmega32u4 when plugged in. 

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Old_Gold_Hand wrote:
Windows recognizes it as an HID, ...
fyi, HID is not available to Windows containers; that issue may not be present in Windows 10X.

COM is available; USB CDC ACM may be available.

Most operating systems limit the instantiations of USB classes (security, USB ports are attack vectors or computer destruction points, signed drivers (.sys), signed shared object (.dll), signed Windows INF)

Add a serial number in the USB enumeration data to enable linking a USB CDC ACM device to a constant COM.

USB CDC is an order of magnitude faster than USB HID; HID is more than adequate for AVR programming (flash page write has a minimum duration)

 

Devices in Containers on Windows | Microsoft Docs

Microsoft announces Windows 10X: A modern OS for foldable PCs coming next year | Windows Central

[Win32, UWP, web apps]

[1/4 page]

...

It also makes Win32 applications more secure by sandboxing and containerizing them so that they can't reach out and affect or damage other parts of the system. 

...

GitHub - appc/spec: App Container Specification and Tooling

Signing Driver | How to Sign Windows Drivers & Executables | Adafruit Learning System

Cryptography Tools - Win32 apps | Microsoft Docs

What is new with Serial in Windows 10 - Microsoft Tech Community - 270855

by George Roussos [Microsoft]

Jul 29, 2015

...

1.   Improved Serial over USB driver support in Windows 10

...

Now devices that report these compatible IDs:

[USB CDC ACM]

… including popular prototyping boards like Arduinos – just work with our built-in driver.

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that, gchapman. After looking at other QMK firmware builds, I cannot tell if keyboards using this chip are using the COM class or HID class.

 

I have been devouring the reset strategies on the datasheet, as well as reading the documentation for QMK (the programmer I plan to use). 

 

Thanks for all the help today, boys

I never knew what I was doing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool project!

Old_Gold_Hand wrote:
After looking at other QMK firmware builds, I cannot tell if keyboards using this chip are using the COM class or HID class.
HID for the application, variable for the bootloader.

DFU would be more of an OOBE wrt mega32U4; DFU is in Atmel Studio 7 and there are a few (several?) other loaders to match Atmel's megaAVR USB DFU bootloader.

Recent macOS sign USB HID.

 

Driver Installation with Zadig - QMK Firmware

Atmel Studio 7 (search for FLIP)

ATMelICE signed dummy kext for MacOS X High Sierra | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Old_Gold_Hand in Post#10 wrote:

I plug in my device, Windows recognizes the ATMEGA32u4, I press the reset button, The DFU bootloader runs, I flash firmware over the USB, I reset again

 

now when i power on the device (plugging it into the USB port), It enumerates (i dont know if im using this correctly) as HID (from firmware?), Windows recognizes it as an HID, and the app runs

 

What is the app that you downloaded? 

The app is most likely causing it to enumerate as HID.

 

In Post#8, the schematic shows a 10K resistor connected from PE2 (HWB) to ground.

If this was working correctly, the 32U4 would always start running the Bootloader, never the app.

I think the 10K is too large, making the input susceptible to noise.

 

Since you want to be able to run both the Bootloader and the app,

you need to replace the 10K resistor with a pushbutton (normally open) switch to gnd,

and add a 10K resistor from Vcc to PE2.

 

To start the Bootloader:  Press and hold the HWB switch, press and release the reset switch,

then release the HWB switch.

 

To start the application firmware, just press and release the reset switch.