Objective Development Forums

You get this error if you link oddebug.o twice or if you link it AND include it in main.c. You should only link this file, not include it.

I don't understand why you get a line of blank lines, but let's ignore this for the moment.

AVR-USB uses DBG1() and DBG2() to print debug info. These are macros which expand to odDebug() when debugging is enabled. You should at least see "ff:" when a USB reset is detected.

EMI is a very general term. I don't mean external influence, hence no shielding. I mean cross-coupling due to bad routing or long routes to blocking capacitors. With the voltmeter you should be able to check whether there are electrical differences between the modes where the device enumerates at th...

You should expect hexadecimal output in the format:

01: 02 03 04 05 06

See oddebug.h for the initialization of the UART and oddebug.c for how the data is actually output. Newer devices might require additional initialization.

I doubt that changing the wires helps. A wire is a wire..

Do you have a scope or at least a multimeter to check the basics such as supply?

Regardless of whether I/O lines are broken or not, USB should work as long as these I/O lines are OK. And I can think of no situation where the AVR should not respond correctly to USB requests, regardless of the status of all other I/O lines. If the device fails to respond on the USB, the AVR must e...

Sorry, no idea. This problem is very strange since you can get both modes to work, but not with the intended selection criterion...

Did you check parity settings etc? You need 8 bit no parity. And are you sure that your level converter works correctly?

I doubt that a resistor, capacitor or diode is broken. You can check the 74HC126 by removing it from the circuit. This will break ISP, but the device should be recognized correctly on the USB side.

I'm using Kermit on Unix. Not because it's so good, but because it's so old that it has always been around and I'm somewhat used to it.

You must do a make clean after enabling debug because there are no dependencies in the Makefile. The output should be at 19200 bps and you must have F_CPU defined.

USB RESET is when D+ and D- are both 0 for more than a couple of bits. The host sends USB RESET after connecting or when it sees other reasons for a reset (e.g. timeout during enumeration). AVR-USB detects a RESET in usbPoll(). If it sees a RESET, it runs the hook macro when the reset status begins ...

We calibrate on every USB reset anyway. But if the device starts without USB connection, it's good to have a guess value available from last time. Other functionality of the firmware may require accurate timing, too.

That should be OK. Maybe the pull-up is too high?

This might be watchdog resets. Calibration takes a while. If your watchdog is too fast, it will cause a reset.