Objective Development Forums

Thanks a lot for this suggestion! Seems logical and should solve the problem in a much more elegant way!

I'll include this in the next release!

Do this after opening the device in your host side software's main.

When you use the original firmware, did you realize that you must prepare the device with a hardware reset in order to activate the boot loader? And the boot loader exits after each connection by avrdude.

Other than that: Did you check with USB Prober that the USB IDs are those expected by avrdude?

As far as I know, there is no reliable way. You can probably recognize the OS by the initialization sequence and timing, but that may (and does) change from version to version.

The host software should know on what OS it runs and can communicate it to the device.

If you use interrupts for the UART, you must declare them so that the USB interrupt can interrupt the UART interrupt.

This is an example circuit only. You can use the firmware from the "examples" directory of the latest driver if you modify usbconfig.h to reflect the circuit's pin assignment. You also need to modify Makefile and change the device type to attiny2313.

I want to add a note: Projects based on AVR-CDC don't work on all operating systems and they may fail on some hosts. If you want a device which you can sell to others, please find a different solution. If you want something which works for you, then just build it.

You can't use AVR-Doper in parallel programming (PP) mode. This is not (yet) implemented. You need AVRminiProg for that. AVR-Doper implements HVSP and ISP only.

For HID mode, please use "-P avrdoper" instead of "-P usb".

You need to write a driver on the device side which makes the EEPROM available to the host. See the Automator project for an example how this can be done.

I remember to have seen this type of error, but I can't remember what caused it. Try to remove the code in step (4) instead of commenting it out.

For access to the EEPROM, see the header avr/eeprom.h in avr-libc. Use e.g. eeprom_write_byte() and eeprom_read_byte().

OK, I finally had the time to try this myself. It works well with my computer (a Macbook Pro) and as you reported, it depends on the AVR's clock rate. The problem is therefore very likely not an implementation bug in AVR-Doper, but the well known reliability problem of CDC mode. It's still not known...

Re (1): I have seen no chip which fails at 3.3 V, although it's outside the spec. Even the 10 MHz devices work. So I assume that it's safe. USB devices and hosts can't be damaged with 5 V levels, the spec demands that. However, some hosts simply don't work with 5 V on D+ and D-. Re (2): In principle...

Thanks for the code!

And yes, a similar error can occur when sending data to the PC. This can only be corrected if we mark the transmit buffer as available only after an ACK is received.

Thanks a lot for this capture! We are lucky and it contains the point of error! It seems it's a bug / transmission error on the host side. The LA capture clearly shows that we send an ACK and the host does not react to it. That's what data toggling is good for, after all. Here's the decoded capture....