I intend to use my AT90USB162 (integrated as a Minumus AVR USB board) as a class of communication device with COMPORT. In the Minimus AVR home site, he gives the code to create a hexadecimal instance of COMPOT for my chip in AVR-USB-162-CDC.zip (this project uses WinAVR 4, but you can create it using WinAVR 5, see Building the AVR Studio 4 project in AVR Studio 5 ). When I create the code, I load the hex file into the chip and do a reset. The problem is that my Windows 7-64 does not recognize the addition of a new COMPORT, so I can not access it from the device manager (and therefore not from Hyperterminal), in fact, when I connect the built-in chip to the USB port , Nothing happens.
So, I need my Windows to recognize my chip as USB-COMPORT for my AT90USB162. How can I do it? What haven't I done?
I also tried .hex files and drivers from the AVR-CDC website , but in fact the driver for my chip is not available (still I tried to use the others available there). But there is no answer.
Update
I found a note in the Windows AVR-CDC driver section :
(*) Vista / 7 x64 does not accept unauthorized kernel-mode drivers. When booting the system you need to disable the "Driver". There is a tool for signing a driver. Subscribers forced protection interceptor See the manual in / vista 64 / Readme64.txt.
So, when I downloaded Overrider to protect driver signatures, I followed the instructions on / vista 64 / Readme64.txt. In short, this should allow Windows to receive the lowcdc.sys and lowcdc.inf CDC drivers that come with the AVR-CDC drivers.
But I didn’t receive an answer.
Refresh
I tested the loading of a microchip on a computer running Windows XP SP3. Therefore, this is not a problem with forcing drivers from Windows 7/64.
Update
I found this: Engbedded AVR Fuse Calculator , but don't know how to use it.
Update
I received the following response from the avrfreaks forum from clawson:
"Try downloading usbdeview.exe to find out what happens during the enumeration. Perhaps a .INF file is needed to display the VID / PID to select the correct driver.
One thing you can do is download LUFA and create an example CDC in it - it almost has to work. "
But it still didn't work. I downloaded usbdeview and tried to see the chip. But when I plug it into the USB port, nothing happens anyway if the .hex file is a CDC.
I also downloaded LUFA and tried to create an example CDC. Not successful. In the make file, I set MCU = at90usb162, F_CPU = 16000000, FLASH_SIZE_KB = 16, BOOT_SECTION_SIZE_KB = 4, and I do not change the rest of the parameters. I also changed the AVR Studio project definitions to install at90usb162. A hex file is generated without errors. But when I try to record a chip, the Flip application returns me the error message “Contact us out of range”. And finally, I realized that the new .hex file is equal to the previous one (without changing the makefile and AVR Studio file).
So maybe someone else has an idea?
Refresh
Perhaps this is a problem with the driver? (and not a problem from .hex?) Any solution?
Refresh
I found the Atmel Application Notes site for this App App AVR296 chip: USB RF Dongle AVRUSBRF01 user guide that describes how to use this chip as a CDC and supplies a .a90 file for writing the chip and a .inf file for use as a Windows driver. I burned my chip with the provided file AVRUSBRF01-AT90USB162-usbdevice_cdc_rf-2_0_1.a90 and installed the at90usbxxx_cdc.inf driver on my Windows. And Windows successfully recognized COMPORT, so the problem is not in the chip, perhaps in the CDC demo itself.
So, can anyone determine where the error / error is in the code?