Objective Development Forums

Hi,

I've built the AVR-Doper without the HVSP parts accorfing to the schema found at http://www.rototron.info/?Page=USBAVR/USBAVR.aspx and it works - kind of...

When the HID jumper is set, AVR Doper is recognized in CDC mode.
When the HID jumper is set and I connect pin 27 of the ATmega8 to GND with an additional wire, AVR Doper is recognized in HID mode.
When the HID jumper is not set AVR Doper is not recognized at all, connecting pin 27 to GND or not makes no difference.

I've checked the soldering/wiring a dozen times to make sure it conforms to the Rototron schematic and I've also cross-checked with the obdev schematic. I've also checked that the resistor that is between the jumper and pin 27 and it has 975 Ohm, which should be ok in my opinion.

What could be wrong? Any ideas on how to fix this?

I want the HID jumper to work as intended.

Apart from this the device seems to work. I've only had the time to read some fuse bits yet. This worked like a charm, but I guess that this proves that the device actually works.

Any help would be greatly appreciated.

Is it possible that you used a 74LS instead of the HC type? HID mode is detected by using the AVR's internal pull-up and see whether we get high or low level. This works only if the load (the 74HC chip) has a high input impedance.

I definately have the 74HC126 chip - at least that is what the bill says and what is printed on the IC.
Would a wrong buffer chip also account for the device not even being detected when the jumper is not set?
Can you imagine anything else causing this behaviour?

I could of course just hardwire what is now running via the jumper and make the additional wire mentioned in the earlier post run via the jumper, but I am not sure that this would be a good idea.

You're right, that would not explain why it does not enumerate without the jumper. That's really strange, because the firmware has no mode where USB is not operational. I would therefore suspect that this is a hardware problem, e.g. not connected supply or GND for the 74HC126 or the AVR or something similar.

I've just re-checked everything: I made sure everything is connected exactly the same way as it is on the plan, I've made sure all solder joints are ok and still ist shows the same behavior that I described in the initial post. I've checked that there is no short circuit anywhere, too.
Could it be some faulty capacitor, zener diode or resistor? (although I can't think of how a resistor could get corrupted)
Is there a way to make sure the 74HC126N is working correctly?
I guess the ATmega8 is ok because if it were not the device couldn't be recognized as AVR-Doper.
Could I have missed anything else?

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 just tested without the 74HC126 - same behavior
so it is not the 74HC126?
that's good because I don't have to replace it, but what else could it be if neither the buffer nor a capacitor, resistor or diode?

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

I am not sure if both modes really do work, because I didn't have the chance to program an AVR with the device yet - I'm building a PCB at the moment that will have an ATmega8 that I will try to program with this home-made AVR-Doper.

All I can say for sure is that I can get the device to be recognized as either HID device or CDC device using the aforementioned methods.

When I have tried to actually program an AVR with this I can investigate further.

I'm beginning to suspect that the ATmega8 that is built into the AVR-Doper has one or more faulty input lines but the port that is used for USB communication is fine.
That's the only explanation I can think of right now...

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 execute code in a different way or not execute it at all. Is it possible that you have glitches on the supply or other EMI problems? Coupling to the RESET line? A supply voltage close to the brownout limit?

hm, sorry, I don't know what EMI problems are, but I've checked the soldering more than a dozen times.

I have also no Idea what you mean by coupling to the RESET line - I guess you mean that the AVR gets a reset signal in the middle of working. I don't know where that should come from, but I'll check the soldering in that part again. I'll probably recheck the whole soldering or even get other wires and replace all the wires (Litze gegen Klingeldraht tauschen).

Supply close to brownout limit? I don't know - maybe. The AVR-Doper is connected to my Laptop without any hub in between and the Laptop is on AC supply.
I don't have a power source for the AVR-Doper apart from what the USB port is delivering.

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?

I don't have an oscilloscope, but I do have a multimeter - I used it to check that there are no short circuits and that everything is connected the way it should be

Guest wrote:I don't have an oscilloscope, but I do have a multimeter - I used it to check that there are no short circuits and that everything is connected the way it should be

that was me - I didn't notice that I was not logged in anymore...

PS: I looked up what you meant by EMI problems - I don't think electromagnetical interference is an issue, but I'll see whether I can shield the device in any way...

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 the host and modes where it does not.