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?
Best Answer
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.