I have an ATmega32U4 chip which can be wired up on a PCB and connected to a PC via USB. When this is done, Windows 10 (if the proper drivers are installed) recognizes the device as ATmega32U4 chip.

What is responsible in the chip to respond to the USB connector? How does this work exactly?

  • Is that also a so-called boot loader which is stored in flash?
  • Is it software shipped by Atmel which is stored in flash? Because then what would happen when I rewrite the flash memory? Would it then no longer be recognizable by Windows?

On a microcontroller like the ATmeaga32u4, those USB pins are connected to a little bit of special hardware to handle USB signalling. But that hardware pretty much just does the electronics, it doesn't control what data is sent or received. And data must be sent and received to identify the device and enumerate. If there is no software on the chip, no data is sent, and the chip will not enumerate at all. Windows will probably report that "one of the USB devices connected to this computer has malfunctioned", but it might not even detect it at all.

But the chips usually come from the factory with a DFU bootloader on them (though completely blank and differently programmed chips are also available). The DFU bootloader identifies itself as a DFU class device, and also gives the PC a Vendor ID (VID) and Product ID (PID). The PC then looks through it's list of drivers to find one which claims to support that VID and PID. You presumably have installed Atmel Flip, which includes a driver, and the driver knows that that VID/PID mean an ATmega32u4 with DFU bootloader. So windows loads that driver, and the driver tells windows that it is a ATmega32u4.

Presumably, you want to do something else with the chip in the long run. So you'll need to program it with your own application. You can't (and wouldn't want to) run the bootloader and your application at the same time. But you can leave them both on the chip, and switch back and forth with some special code, fuse settings, or by pulling a pin to ground during reset. This is great for development, because that bootloader can be used to upload a new copy of your application. It's also handy if you want to let customers do firmware upgrades in the future.

But while your application is running, the bootloader is not. So the bootloader can't do the enumeration, can't pass the VID/PID to the computer etc. Instead, your application will have to do all that. And it's complicated. But the good news is that there are libraries which do most of it for you. The most common is called LUFA. You will also need to buy/choose your own VID/PID, and write a driver to go with your device.

  • \$\begingroup\$ Thanks for the additional information! So when I wrote my own compiled .HEX file to the ATmega32u4 flash I typically did not erase the factory default bootloader? How could I (re)activate the bootloader so that Windows detects the chip again (and thus I could again flash another program to it)? \$\endgroup\$ – bas Apr 15 '17 at 12:36
  • \$\begingroup\$ When you program the chip with a programmer, there's usually an option to "erase first". If that's ticked, the bootloader gets erased, if not then it doesn't. If you program with the bootloader, it won't delete itself. If the bootloader is still there, you can start it by 1) setting the BOOTRST fuse, 2) Pulling the HWB pin to ground during a reset (requires HWBEN fuse) or 3) a JMP instruction in your application. See atmel.com/Images/doc7618.pdf \$\endgroup\$ – Jack B Apr 15 '17 at 13:34
  • \$\begingroup\$ @JackB. The DFU bootloader is not erased if you 'erase first' before programming via the DFU. The bootloader is in a protected set of pages and you have to use an ICSP to clear the protection fuses. The DFU documentation is updated, see here: atmel.com/Images/doc7745.pdf \$\endgroup\$ – Jack Creasey Apr 15 '17 at 17:13

So, on microcontrollers, you have to write firmware that handles USB, and that includes reacting to packets from the host that ask for things like vendor and product IDs.

So, there's software running on your microcontroller that talks to your PC according to the USB standard.

Chances are, that yes, this is bootloader firmware that came pre-flashed by atmel - the reason is simply to allow you to build a device and then program it quickly. Super handy for production!

Whether or not that bootloader resides in user-writable memory and under which circumstances it is run at start depends very much. Your devices data sheet and user guides will have details on that. Look for Bootloader, USB, and possibly "DFU", the USB profile for firmware uploads.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.