Arduino auto-shutoff? Self-protection?

Hi all,

I've got an Uno R3 hooked up to an ArduiNix shield in order to build a Nixie display. The Arduinix basically just takes a few Arduino outputs and allows them to control a separate 180V supply.

When I hook the shield up to one of the nixie tubes, it runs great for a while, and then the Ard quits sending output to its pins. (I've got an LED on the pin in question, and a voltmeter on the test point in the shield, so I know the Arduino has stopped sending that pin high and not just something going wrong on the shield.) If I reset the Arduino, everything comes back on again.

It doesn't do this when the tube isn't connected (the LED stays lit indefinitely). What would cause the Arduino to stop sending outputs to its pins like this? Is it a load problem? Is there some protection fuse getting tripped? I don't expect users here to trace the shield schematic and everything, but what should I be looking into or metering in order to figure out what's going on?

Thanks!

Risen:
When I hook the shield up to one of the nixie tubes, it runs great for a while, and then the Ard quits sending output to its pins.

How long is a "a great while"? My watch doesn't have that increment.

Risen:
so I know the Arduino has stopped sending that pin high and not just something going wrong on the shield.)

The Arduino doesn't "send pins High". Is your code toggling that pin? (And you do have a current limiting resistor in series with that LED, right?) If your code isn't directly changing the state of the pin, you won't really have much debug information to go on.

Risen:
If I reset the Arduino, everything comes back on again

Pressing just the RESET button and getting back to normal operation, might suggest a code problem. 1) Running out of RAM. 2) not declaring variables for millis() and micros() correctly. 3) Not handling rollover of millis() and micros(). etc.

Risen:
Is there some protection fuse getting tripped?

There is a poly-fuse on the USB supply line. However, a simple press of the Reset-button generally wouldn't reset it. A power cycle (and sometimes a few seconds of power-down) is needed to let the polymer cool down.

Risen:
I don't expect users here to trace the shield schematic and everything

Probably a good idea to set your expectation there. It is really tough to trace a schematic or debug code that isn't posted. (Hint: Nobody ever complained about someone posting their code and schematic along with their question.)

Thanks-- some good things to think about and clarify.

It appears to depend how much the displayed tube is changing. Sometimes this is only a few seconds, other times it's a few minutes.

The code is multiplexing, so the pin should be rapidly changing state. Result is that the LED is mostly on all of the time. (When I'm describing "on" here, I'm really talking about a quick pulsing, consistent with the multiplexing I'm doing here -- not a constant on.)

Yep!

I'm happy to look into any or all of these, but it doesn't explain why the LED shows normal operation until I've got the tube in place.

How would I go about figuring out if I've run out of RAM?
Not using micros() anywhere.
All vars recording millis() are LONG. I know I'm not handling the overflows on those yet, but I thought I didn't need to worry about that for the first 9 hours or so? I was going to add my overflow handling in later.

Hmm. That does suggest a code problem. Not sure how attaching the tube would alter how the code was running, though? I'm not attempting to use any input here.

My code is getting pretty complicated; perhaps I can create a reduced sketch that reproduces the problem and post that.

If things work until you hook up hardware that's a sign, generally, that you have an electrical problem. For example, noise from the tubes is causing things to go wrong. Or they are drawing more current than you can provide.

Okay, here's something interesting I just figured out: polling I2C is causing jitter somewhere. I'm reading data from an RTC over A4/A5. When I read it, I'm getting momentary changes on the tube output pins. If I read data more often, this "crash" happens far quicker than if I poll less often.

Clearly I need to debug what I'm getting for data from the RTC, but it doesn't really explain the "crash" I'm getting here. Is there a known conflict with other pins when using I2C? I haven't seen it mentioned anywhere.

Without seeing your sketch, and your wiring, it's all guesswork.

Having said that, you shouldn't be "polling" I2C. Maybe your terminology is different to mine there.

Thanks.

I'm fairly new to the electronics side of things, so I may not be using the proper terminology. I'm describing a simple "read" from my RTC.

I'm going to do some more testing and debugging on this end. If it's evident that this isn't a problem with how the hardware is working, I'll post some diagrams and code into the proper area of the forum. I don't think this would be the right section to do that.

I think I've traced this to a problem with an unstable connection between the Arduino and the RTC on the I2C lines. Since that strongly suggests this is not a problem with the Arduino hardware, I'm going to consider this thread solved. It's the wrong part of the forum to discuss my project specifically.

Thanks for the help.