Fried another two programmers :-(

I used to use a USBtinyISP, until that broke.
Then, I got a Pololu programmer, which worked fine for 5V, but not for 3.3V.
Then, I got an actual AVRISPv2 from Digi-Key, which could do both.
But, today both of them stopped working, coincidentally (?) after I had them hooked up to a board that has my new H-bridge connected (which in turn is connected to a motor.)
I tried both of them with avrdude from the command line, on a plain Atmega328p on a plain Uno R3 board with nothing connected, and they still fail. The ISPv2 is telling me all three tests fail (MOSI, RST, SCK) and that the connector is inserted wrong, no matter which way I attach it.

I can only assume that the problem is that spikes/transients on the power line from the motors are frying the programmers. It's kind-of weird, though, because this is pretty well filtered. There's a 1 uF ceramic across the input, which comes from a 2S LiPo. This branches off to the H-bridge and motor, and to an LM350 regulator. Out from the regulator is 6" power cables, that enter the AVR board to a 10 uF tantalum electrolytic. The AVR itself is further de-coupled with a 0.1 uF ceramic, and the analog voltage has another 1 uF ceramic across it (although on the other end of a 1 uH inductor.) So I kind-of wonder how those spikes could really make it to the AVR and ICSP header, but that's the best theory I have to go on.

Of course this happens a Friday night, and Jameco is closed over the week-end, and it's too late to order Saturday delivery from Amazon (or Digi-Key or whatever). I actually have enough parts at home that I could build a USBtiny -- if only I could program it! So, I find myself stranded without a programmer again :frowning: Perhaps I'll pick up a fresh Uno from Radio Shack and hot-wire that...

So, when I get/make my next programmer, what should I do to protect it? TVS-es across power/ground, as well as each signal line? An additional Zener across 5V on the AVR board? Any other ideas?

Post a schematic - I didn't see any mention of diodes across the motors.

I know you can fry a USBtinyISP if you short an output and it draws too much current, better the USBtinyISP blows than your motherboard. I love the little USBtinyISP they are cheap and they work, too bad AVR Studio does not support them directly.

The ATMEL AVRISP Mk II is a great programmer too, I have two on my bench, but the cost is much more than the little USBtinyISP.

Just my 2 cents,

wade

wwbrown:
I know you can fry a USBtinyISP if you short an output and it draws too much current, better the USBtinyISP blows than your motherboard.

Too much current where? Through the SPI bus line or through the +5V power line?

Can you fix it by replacing the ATtiny2313? (how would you burn the program without a programmer :-S )

CrossRoads:
Post a schematic - I didn’t see any mention of diodes across the motors.

Thanks for the suggestion! It’s an H-bridge going both ways – I can’t really use diodes there.
The N-channel MOSFETs (high and low – driven by IRS2301 drivers) have built-in body diodes that go the way they can go.
The controller code grounds out both terminals for 10 microseconds when switching power, to help out. I’ve verified this on a scope. (Well, a Saleae USB logic analyzer)

As I said, the AVR is on the other end of a LM350 regulator and a bunch of capacitance. This should protect against spikes AFAICT. And the AVR itself is actually fine – it’s the connected programmers that get screwed up, and I’m looking for ways to make that not happen. It seems like a programmer dev tool should be able to be robustified enough to take all kinds of abuse…

Is there a RuggeduISP? :slight_smile:

fungus:
(how would you burn the program without a programmer :-S )

Exactly my problem :slight_smile:

I have a mk II programmer, but that's one of the ones that no longer works.

My Arduinos have all been re-flashed without bootloaders, so I had to go get a virgin Uno. I can use that as serial programmer now, so that's something. A bit slow... And not robust at all, as the wires go straight into the AVR pins.

jwatte:

CrossRoads:
Post a schematic - I didn't see any mention of diodes across the motors.

Thanks for the suggestion! It's an H-bridge going both ways -- I can't really use diodes there.
The N-channel MOSFETs (high and low -- driven by IRS2301 drivers) have built-in body diodes that go the way they can go.

Picture the diodes as a full-wave bridge -- with the commoned cathodes connected to +V, the commoned anodes to Ground, and each electrode of the motor connected to one of the cathode-anode junctions (where the AC would go in, in a power supply.)

Those "body diodes" aren't acceptable as flyback diodes (I say, "No Way!")

          • Or keep your motor unpowered till after you unplug your programmer.
            I can sketch out the diode arrangement, if necessary.

jwatte:

fungus:
(how would you burn the program without a programmer :-S )

Exactly my problem :slight_smile:

You can use ArduinoISP to burn the firmware on a new Attiny2313. Refer to the schematics used to burn the bootloader on the Atmega328 and connect MOSI/MISO/SCK/RST (plus 5+ and GND) from the Arduino to the Attiny2313, then thorugh the terminal (Linux) or command line (Windows) burn the firmware (the .hex file available from the Adafruit site) and that's it.

Those "body diodes" aren't acceptable as flyback diodes

Thanks for your clarification! I appreciate it.

To make sure I understand your suggestion: The arrangement you suggest is exactly the same arrangement that the body diodes is providing, right? Your suggestion is that the body diodes are poor performance as flyback diodes, and I should double them up with something better?
Can I use some 1N4001s? Do I need a high-voltage Schottky? Something else?

I have noticed that some motors I've, ahem, "destructively analyzed" in the past have had capacitors across the poles. Is that a good idea? How should I match up the capacitance to the motor and PWM frequency if that's the case? What max voltage is needed? (I have a 250 V 1 uF film capacitor around here somewhere... and a slew of 50V 0.1 uF ceramics for decoupling)

leo72:
You can use ArduinoISP to burn the firmware

That ended up being exactly what I did. The problem was that I had no Arduino board left with the serial bootloader installed, so I was catch-22. I had to do a Radio Shack run to pick up a new Uno – luckily they close late :slight_smile:

Also, I now have an additional 1000 uF on the input to the LM350 regulator (the regulator needs to be beefy, because it also runs a servo – hmm, that’s also a motor …) And a 6.8V 600W TVS across the input to the AVR board. I figure it can’t hurt :slight_smile:

jwatte:
The arrangement you suggest is exactly the same arrangement that the body diodes is providing, right? Your suggestion is that the body diodes are poor performance as flyback diodes, and I should double them up with something better?
Can I use some 1N4001s? Do I need a high-voltage Schottky? Something else?

Yes, same arrangement - across the FETs.
You don't need "high voltage" PIV, >= 1.5 * V_supply ought to do it, because they're normally back-biased. When they conduct, it's all about forward current. Schottky is best , but a decent rectifier is better than the "body diode" (which is a zener equiv, after all.)

The cap network on the motor is for noise reduction which I doubt is your issue.

Like I posted last, the very best way I can think of to preserve your USBtinyISP (et al.):
Disconnect motor voltage before and during re-programming (or anytime that the USBtinyISP is connected.)

On this occasion, I strongly disagree with RP. It's entirely usual to use the body diodes of power mosfets as the flyback diodes in a mosfet H-bridge. 1N4001 and similar diodes are much less suitable because they don't switch off as fast. The only reason not to rely on the mosfet body diodes is if there is so much energy flowing through them from the motor that the mosfets get hot. In this case, using Schottky flyback diodes would be an advantage. You would need to be using a very large motor for this to be a consideration.

What you DO need is a large capacitor between the motor supply +ve and motor supply ground terminals of the H-bridge, to absorb the power flowing through the flyback diodes (whether you are using external flyback diodes or not). Something like 1000uF electrolytic in parallel with 1uF or greater ceramic.

Single mosfets driving motors are a different matter entirely. In that configuration, the body diode is in the wrong place in the circuit to act as a flyback diode. With an H-bridge, the body diode of the upper mosfet acts as the flyback diode when the lower mosfet turns off, and vice versa.

Something like 1000uF electrolytic

Thank you for the suggestion! That's actually exactly what I just added. Also thanks for the description of flyback diode requirements. This gives me a better understanding of the situation.

Now, whether that is actually what blew the programmers is a second question... But what else could it be?

JYE Tech have their own version of the USBasp, which triples as a dev board and also as Uart/USB converter .
despite having a usntiny, i have come to love this one, instead due to its ease of use.
Seed studio sells them by the way, and JYE tech have a top notch customer support if needed

That looks nice, too! It would need a 10-to-6 converter for use with 6-pin headers, though.

I ended up ordering two of the SparkFun programmers (same price as the JYE) so I can keep one in reserve for when the first one blows, and won't be stranded over another week-end :slight_smile: That comes with a cable that's 10-pin and 6-pin all-in-one. Until those arrive, I'm limping along with Uno-as-ISP.

jwatte:
Now, whether that is actually what blew the programmers is a second question... But what else could it be?

  1. In your circuit, what are the MOSI, MISO and SCLK pins connected to, apart from the ICSP header?

  2. Do you disconnect power to the H-bridge when you have the ICSP programming cable connected?

dc42:

  1. In your circuit, what are the MOSI, MISO and SCLK pins connected to, apart from the ICSP header?

They go to another similar header that is connected to a nRF24L01+ 2.4 GHz radio. Although I often disconnect that when programming, because if I start programming right when a packet is on the wire, the radio confuses the programmer.

  1. Do you disconnect power to the H-bridge when you have the ICSP programming cable connected?

Nope. Hence, why this is my prime suspect :slight_smile: I'd love for a programmer to be robust enough to not need that, though. TVS-es and current limiting resistors on all wires, buffering, etc. Maybe some parallel caps, too, for filtering. The USBtinyISP actually has buffers, but not TVS-es -- if you blow something, it's more likely the buffer than the 2313.

I just want to make sure I'm not overlooking something else.

FWIW: I hadn't noticed how extremely current hungry that pair of motors is (it's two motors on one H-bridge) -- my bench power supply drops from 8.2V to less than 6V when they start, even though I'm using PWM, and the current limit is set to 5A. On battery, I don't have that problem -- yay for high-C LiPo packs :slight_smile: And also, yay for MOSFETs that can take > 20 A :slight_smile:

  1. Have you kept the ground wire from the PSU to the H-bridge separate from the ground wire to the ICSP header?

  2. When programming, is there a ground loop? i.e. the programmer is grounded through the PC USB port, and your bench power supply may also have its negative terminal grounded. If so, when the H-bridge switches, there will substantial ground loop currents (especially if you don't have those capacitors I mentioned close to the H-bridge mosfets), and that may be what's killing the programmers. You could try connecting 100 ohm resistors in series with all the ICSP header pins (including ground) and not connecting the +5V ICSP header pin.

Thank you, I appreciate your recommendations! Finding all i-s to dot and t-s to cross to make sure this isn't a recurring theme is important to me :slight_smile:

The PC is powered by the same bench PSU (a second channel) because it' on-board on the robot that also has the motor controller.

There is some common ground (heh) and then a Y split to H-bridge vs LM350 regulator, after which there's a short cable (6") to the controller board. That Y splitter now has the big capacitor; it didn't before.

I did remove the 5V connector from my arduino-based programmer. I don't think I can do it for the others, because they use presence of 5V as a detector for an inserted cable. (The AVRISPmk2 also detects that RST can be pulled low, and if not, detects a reversed cable.) The USBtinyISP design has current limiting resistors on the programming pins already, but not on the 5V.

It may be worth putting a current limiting resistors in series with your 5V and ground ICSP pins then.