Objective Development Forums

Yes, I just found that out yesterday! We will release a new version with a fixed template soon.

If you want to fix your template, load the template project at /usr/local/AVRMacPack/etc/templates/TemplateProject and change it. You may have to be root in order to edit the template.

You MUST NOT set the jumper for device supply if you have an external supply connected! This may even damage your computer (although computers have a self-resetting fuse in the USB supply these days). If you disconnect the battery, the device CAN be supplied by the programmer if the device's ISP con...

It looks as if reading the device descriptors failed, since no information whatsoever is given about the device. Since reading the descriptors is the very first thing the host does, this probably means that USB connectivity does not work at all. Please check the usual things like - fuse values: Does...

Yes, that should work. Probably even better. Only 74LS and 74 standard don't work.

As far as I can see, this is NOT a USB problem, but a problem in the communication between the programmer and the target device. Did you use an 74HC type for the ISP driver?

Three more things that come to my mind: (1) Did you compile for the ATMega8 or the ATMega88? They are not binary compatible. (2) Did you check wiring, especially pin assignments of the USB connector (unless you used a known-to-work PCB, of course)? (3) Did you try to insert a hub between the host an...

For endpoints 0, 1 and 3 (this is the default endpoint number, actual numbers may be assigned differently), there are global variables volatile uchar usbTxLen; volatile uchar usbTxLen1; volatile uchar usbTxLen3; (only usbTxLen1 and usbTxLen3 are declared extern in the header, if you need to stall en...

This can be almost anything. That's why I recommended to start with a working example and change only one thing at a time.

Does it report the device name for the unknown device? If it knows the device name and vendor name, then the USB driver works. In this case you need to associate libusb with the device. This is usually done with a .inf file. If the device is completely unknown, there's probably a more fundamental er...

This is a different problem than what you reported before. -lusb is libusb-win32. You should install it at a path where it can be found by the compiler (or add -L and -I flags to extend the search path). See http://libusb-win32.sourceforge.net/.

I see, igor's programmer includes the firmware file in the executable. There are many parallel port programmers available for zero-cost AVR programming. See for example m or search the web for low cost AVR programmers. You may even find programming software which is compatible with Igor's pin assign...

I would recommend that you start analytically: Use one of the reference projects on an ATMega8 and get it running. Then move this same project over to the ATMega32, updating the usbconfig.h and other pin assignments as well as fuse values accordingly. Then bring in your firmware code, taking care th...

OK. One thing after the other. Please make sure that the device is recognized by Windows. I don't know how you can distinguish a broken device from a device without drivers on Windows, but there should be a way to do that. Regarding the host application: Please make sure you can compile a simple &qu...

As you can see, this is a verify error reported by avrdude. This may be a wiring problem, a bug in avrdude or your chip is broken.

The first error can be solved by re-installing MinGW, not WinAVR.

I'm afraid I don't understand your last comment about the hex file. But if a hex file is generated, no error occurred, only warnings.