ATmega8 stops executing

Here's hoping somebody recognizes this problem and knows the solution.

I'm using an ATmega8 to control a freezer. When I started the board up, it ran great for about ten minutes, then froze in place - outputs that were on stayed on, and communication with the 7-segment display and the temperature sensor stopped.

Cycled power, and it ran normally again for a few seconds, then quit in the same way.

The longer I let it sit between attempts to use it, the longer the board will run, but eventually (and soon) it always fails in this way.

Has anyone seen this problem? Do you know what I'm doing wrong?

Thanks in advance-
Wesley

Well if it's stopping with some outputs still active it kind of sounds like a clocking problem. What are you using for the system clock?

I'm using the internal clock.

Hard to see how it's a clocking problem, though. The main loop is supposed to continue executing indefinitely, at whatever speed.

Even if the timing was screwed up, I'd expect to see gibberish on the display, not freezing at the current value.

-W

Is there a sleep mode that leaves I/O pins in their current states? Wondering if this might be a brown-out or something...

-W

@wesley: by default all sleep modes will keep the pins in their programmed states.

How do you know that it acutally locks? How do you know that it is not the power supply that causes the issue? Or the display? Or your code?

If you suspect the hardware: what about a small program that just blinks a LED. Will it still crash?

Udo

Have you built much of the extra electronics yourself. Have you got an y decoupling:-
http://www.thebox.myzen.co.uk/Tutorial/De-coupling.html

good tip. I've just programmed a simple flashing routine, and it's running without any trouble for about a minute... longer than I was getting before. I don't think the display is the trouble, since it displays all traffic going past during program cycles without fail, even when execution has 'locked up'.

I wonder if the OneWire library might be causing trouble... I'll import it, run the flasher.

If that works, I'll start adding the I/O pins back, and running the flasher.

we'll get it.

-W

Have you thought about using the watchdog?

I built all the external hardware myself. It could definitely be the problem.

My digital out pin feeds (through a 1K resistor) the base of an NPN transistor. When saturated, the transistor allows current to flow in the coil of a relay. So I don’t think I’m drawing too much current there.

I’ve got a OneWire temperature sensor, which includes a 5.2K pull-up resistor between the I/O pin and Vcc. I think that’s ok, too.

(OneWire library: http://www.pjrc.com/teensy/td_libs_OneWire.html)

And I’ve got my SPI port connected to a SparkFun 7-seg serial display. I think that’s ok.

And The problem occurs whether I’m powering the MCU from my power supply or from the programmer, so coupling seems unlikely, especially since the blinky circuit worked.

Pretty simple circuit, so I’m suspecting the programming. I wonder if my spi_transfer function may fail to return?

char spi_transfer(volatile char data)
{
  //delay(1);
  SPDR = data;                    // Start the transmission
  while (!(SPSR & (1<<SPIF)))     // Wait the end of the transmission
  {
  };
  return SPDR;                    // return the received byte
}

Thanks for the replies so far, guys!

Watchdog?

What happens if you disconnect or disable components? One at a time. Which one starts the crash behaviour?

The display might be the cause, the relais just as well...

Udo

OK, this is funky...

I went into my controller program and replaced the part that turns the freezer on and off based on a setpoint with code to toggle once per second. Program the board and leave the programmer attached (power is through the external supply, though.

I cycle power to the board.

Code runs for a couple seconds, then locks up.

I unplug the programmer.

The relay toggles, once.

I plug the programmer back in.

The relay toggles, once.

So I'm pretty sure now that the problem is an SPI transfer to the display that never finishes. Probably a sketchy solder joint prevents the display from receiving or acknowledging data (not sure whether SPI needs this, tho...), which would explain why it occurs only after the thing's warmed up (I've had that thing soldered and resoldered too many times to count, trying to make her run. Probably damaged a pin.)

So, I'm off to resolder all the pins! wish me luck!

-W

I elected not to resolder the display. Instead I just commented out all the code where I would have communicated with it.

Except for the display (which was supposed to display the current temperature in the freezer), the project works as desired. I’ll come back to fix the display at a later time, but I needed this baby running so I could lager a Kolsch while I’m on vacation for two weeks. Woot!

-Wesley