I intend to use my AT90USB162 (integrated as Minumus AVR USB board) as a Communication Device Class with COMPORT. In Minimus AVR home site, it gives an code for building a COMPORT hex to my chip, in AVR-USB-162-CDC.zip (this project uses WinAVR 4, but you can build it using WinAVR 5 too, see Build AVR Studio 4 project in AVR Studio 5). As I build the code, I load the hex file into the chip and make an reset. The problem is that my Windows 7-64 does not recognize the addition of the new COMPORT so I cannot access it from Device Manager (and thus neither from Hyperterminal), actually when I plug the built chip on the USB port, it happens nothing.
So, I need to make my Windows recognize my chip as an USB COMPORT for my AT90USB162. How can I do it? What didn't I do?
I also tried the .hex files and drivers from AVR-CDC site, but actually a driver for my chip is not available (still I tried using other ones available from there). But no response.
Update
I found a note in AVR-CDC Windows Driver Section saying:
(*) Vista/7 x64 does not accept unauthorized kernel-mode drivers. You have to turn "Driver > Signature Enforcement" off during system boot- up. There is a tool to sign the driver. Driver Signature Enforcement Overrider See the instruction in /vista64/Readme64.txt.
So as I downloaded the Driver Signature Enforcement Overrider, I followed the instructions on /vista64/Readme64.txt. In brief, it should enable Windows to receive the CDC drivers lowcdc.sys and lowcdc.inf, which comes with AVR-CDC drivers.
But still got no response.
Update
I tested loading the microchip on a Windows XP SP3 machine. So it's not a Driver Signature Enforcement problem from Windows 7/64.
Update
I've found this: Engbedded AVR Fuse Calculator but don't have any idea on how using this.
Update
I got the following answer from avrfreaks forum from user clawson:
"Try downloading usbdeview.exe to see what happens during enumeration. It could be that the VID/PID presented requires a .inf file to select the correct driver.
One thing you could do is download LUFA and build a CDC example in that - it's almost bound to work."
But still did not work. I downloaded usbdeview and tried to watch the chip. But when I plug it in USB port, it still happens nothing if the .hex burned file is the CDC.
I also downloaded LUFA and tried to build the CDC example. Got no success too. In makefile I set MCU = at90usb162, F_CPU = 16000000, FLASH_SIZE_KB = 16, BOOT_SECTION_SIZE_KB = 4 and the other parameters I let unchanged. I also changed AVR Studio project definitions to set at90usb162. The hex file is generately without errors. But when I try to burn the chip, Flip app returns me error message "Address us out of range.". And finally I realized that the new .hex file is equal to the previous one (without changing makefile and AVR Studio project file).
So, maybe does someone more have an idea?
Update
Maybe it's a driver problem? (and not a problem from the .hex?) Any solution?
Update
I found in Atmel Application Notes site for this chip the App Note AVR296: AVRUSBRF01 USB RF Dongle user's guide, which described a way to use this chip as CDC and supplies the .a90 file to burn the chip and the .inf file to use as a Windows driver. I have burned my chip with the AVRUSBRF01-AT90USB162-usbdevice_cdc_rf-2_0_1.a90 file provided and installed the at90usbxxx_cdc.inf driver on my Windows. And Windows recognized the COMPORT successfully, so the problem is not with the chip, probably is on the CDC demo code itself.
So, could someone identify where is the error/mistake in the code?
