AVR keeps restarting!

[Joe]

I am using the ATMEGA644P with a 7.3728 crystal. The microcontroller starts over every time it executes a call to rpirntf followed by a delay. It doesn't even matter if I use delay.h or use my own looping delay, there is no difference. Please look at this code:

Code: [Select]

#include <avr/io.h>
#include <util/delay.h>

#include "uart2.h"
#include "rprintf.h"

void configurePorts(void);

int main (void) {

configurePorts();
uartInit();

rprintfInit(uart0SendByte); // UART0 = DDD1

rprintf("ABC\n\r");

_delay_ms(1000);

rprintf("DEF\n\r");

_delay_ms(1000);

rprintf("GHI\n\r");

return 0;
}

void configurePorts(void) {
// Port B: Only used to scope pins for delay
DDRB = 0xFF; // All Outputs
PORTB = 0xFF; // All High

// Port D: UART0 is DDD1
DDRD = (1 << DDD1);
}

When run, this code prints the ABC, delays for a second, then starts over. I figured delay.h and the UART are having a conflict so I replaced the delay with a loop of my own:

Code: [Select]

void sec(void) {
unsigned long int x;
for (x = 0; x < 780000; x++) {
PORTB ^= (1 << PB0);
}
}

And called "sec" instead of _delay_ms(1000). Same exact thing happened. If I comment out the 1st rprintf call it will do the 1st delay, 2nd rprintf call, 2nd delay, then start over. So basically, a rprintf call followed by any kind of delay causes the uC to reset. Anyone know what I'm doing wrong?

[hopslink]

You have no looping in your main function. The micro is stepping through the code you have then running through the rest of it's program memory (which is usually full of NOP, no operation commands). Eventually the program counter hits the top of the program memory addresses and rolls over to zero, effectively reseting the micro.

Do something like:

Code: [Select]

int main (void) {

Any_setup_code here;

Any_other_run_once_code;

while(1) // indefinite loop
     { 
          Your_repeating_code_here;     
     }

return 0;
}

[Joe]

Thanks for the reply. I have altered the code as shown below but it still restarts exactly the same.

Code: [Select]

#include <avr/io.h>
#include <util/delay.h>

#include "uart2.h"
#include "rprintf.h"

void configurePorts(void);

int main (void) {

configurePorts();
uartInit();

while(1)
rprintfInit(uart0SendByte); // UART0 = DDD1
rprintf("ABC\n\r");
_delay_ms(1000);
rprintf("DEF\n\r");
_delay_ms(1000);
rprintf("GHI\n\r");
}

return 0;
}

void configurePorts(void) {
// Port B: Only used to scope pins for delay
DDRB = 0xFF; // All Outputs
PORTB = 0xFF; // All High

// Port D: UART0 is DDD1
DDRD = (1 << DDD1);
}


[waltr]

I see unbalanced {} in main. I don't know why it would compile without an error.

There should be a { after the while(1) as hopslink showed.

[Joe]

It's there. I must have accidentally deleted it after I pasted it into the post. Actually it is:

Code: [Select]

#include <avr/io.h>
#include <util/delay.h>

#include "uart2.h"
#include "rprintf.h"

void configurePorts(void);

int main (void) {

configurePorts();
uartInit();

while(1) {
rprintfInit(uart0SendByte); // UART0 = DDD1
rprintf("ABC\n\r");
_delay_ms(1000);
rprintf("DEF\n\r");
_delay_ms(1000);
rprintf("GHI\n\r");
}

return 0;
}

void configurePorts(void) {
// Port B: Only used to scope pins for delay
DDRB = 0xFF; // All Outputs
PORTB = 0xFF; // All High

// Port D: UART0 is DDD1
DDRD = (1 << DDD1);
}


[Joe]

Here's something: If I reduce the delay to 2ms or less it executes correctly. Why would that matter?

[dunk]

hi Joe,
in my experience random resetting of a MCU are due to one of 2 things:
1. the watch dog timer being set accidentally.
i don't think this is your problem because your code works with the shorter delay.
it would be worth checking the WDTON fuse bit anyway.

2. some sort of power issue.
i think it is unlikely this is causing your problem because, again, your code works with the shorter delay.
it would be worth confirming your power supply is up to spec anyway.

something to check:
in your _delay_ms() function, what kind of variable is the input defined as?
if it's only and 8bit integer then the maximum valid delay would be 255ms.

also in your own sec() function, x is an "unsigned long int" which should be defined as 32-bit unsigned type which is fine for values of 780000 but it might be worth checking your included source files to make sure it is actually 32 bit.

out of interest, what happens if you repeat the (working) 2ms delay 50 times?


if you can rule out all those then i'm out of ideas.
dunk.

[KurtEck]

Hi,

Dunk probably has hit on most things I can think of, but in the past I have run into other resets of processors and sometimes it is from unhandled faults, like a divide by zero or a hardware interrupt happening.  Earlier I was resetting for example when I had not passed the right number of parameters to rprintf... Some other thoughts include:

1) Not seeing some of the other functions, is your reprintf setup to be buffered output.  I am using buffered in my code and when I was faulting it was not clear where.  So in those cases I added calls to wait until the output buffer was empty...

2) Is it resetting inside the delay or at the start of the next rprintf?  When I hit cases like this, I either try to toggle some on board LEDS (if I have them), lets say right after your call to the delay, to see if I get there...  Or I use my logic analyzer and hook it up to some output pin and try to capture the toggle there...

3) On the same line where you say if I do my own wait function it still faults.  If you do the rprintf followed by a simple for loop that never exits, does it reset?

Good Luck
Kurt