Stack overflow?

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
publius
publius's picture
Level: Wannabe
Joined: Mon. Nov 1, 2004
Posts: 85 View posts
#1
Posted by publius: Tue. Jul 31, 2007 - 04:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi freaks,

I thought my problem from the topic "strange reset" was fixed, I was wrong.

My project, a webserver seems to reset randomly.

I thought it was tack overflow so I connected my JTAGICE to the ATMEGA128 with a data breakpoint at 0x0100.
The program restarts at 0x0000 but the only time the STACKEND is written, is when CVAVR clears the RAM at init, from the .lst file:

__CLEAR_SRAM:
000140 93ed ST X+,R30
000141 9701 SBIW R24,1
000142 f7e9 BRNE __CLEAR_SRAM

I enabled watchdog and brownout at 4V.

I'm lost, any suggestions to what might be the problem and/ or how to locate it?

Thanks in advance.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Bronze Markbobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26667 View posts
Location: Orlando Florida
Posted by bobgardner: Tue. Jul 31, 2007 - 04:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've gone so far as to write a handler for every vector that turns off ints, prints a msg, then hangs in a loop

Imagecraft compiler user

Top
jgmdesign
jgmdesign's picture
Level: Moderator
Joined: Mon. Mar 19, 2007
Posts: 17204 View posts
Location: Long Island New York
Posted by jgmdesign: Tue. Jul 31, 2007 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You mentioned the brownout is set to 4v. Since this reset happens randomly, it would be my guess that the power source is not filtered, and/or regulated.

Is there any regulation or UPS? I'd start there.

The watchdog, can that be disabled as well? If so, why not disable it and see if the device operates as desired. If it does, then there is your culprit, and you must look it the code for a missing watchdog reset.

Regards,
Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Top
publius
publius's picture
Level: Wannabe
Joined: Mon. Nov 1, 2004
Posts: 85 View posts
Posted by publius: Tue. Jul 31, 2007 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When the watchdog an brownout are diasbled the behaviour is the same. I enabled them the make sure that the supply isn't the problem, since then the system would reset.

When the problem occurs it keeps starting from 0x0000 until I toggle the power (reset).

Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99972 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 31, 2007 - 04:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is in MCUCSR at the time of the restart at 0x0000 ? The flags will tell you the reason for the reset.

Cliff

Top
publius
publius's picture
Level: Wannabe
Joined: Mon. Nov 1, 2004
Posts: 85 View posts
Posted by publius: Tue. Jul 31, 2007 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Al these flags are set: JTRF BORF EXTRF PORF.

But I don't think it is a proper reset because then it would opperate correct (for a while). Or Am i mistaken?

I've ruled out stack overflow since a placed HARD and SOFT- ware stack endmarkers and they are still at he correct place in memory.

any ideas?

Top
Mike B
Mike B's picture
Level: Raving Lunatic
Joined: Tue. Jun 22, 2004
Posts: 3839 View posts
Location: South West Utah, USA
Posted by Mike B: Tue. Jul 31, 2007 - 06:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

data sheet MCUCSR description wrote:
To make use of the reset flags to identify a reset condition, the user should read and then reset the MCUCSR as early as possible in the program. If the register is cleared before another reset occurs, the source of the reset can be found by examining the reset flags.
If you do not reset MCUCSR, then you end up with multiple reset flags set.

Top
publius
publius's picture
Level: Wannabe
Joined: Mon. Nov 1, 2004
Posts: 85 View posts
Posted by publius: Tue. Jul 31, 2007 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the problem is that the program jumps to 0x2A which is the ADC complete interrupt. I didn't enable this interrupt so then it jumps to 0x00.

How can this be posible since i didn't enable the ADC complete interrupt?

I will clear the MCUCSR soon but if I do the program needs to be reloaded and it could take a week before this problem occurs again.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39870 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Jul 31, 2007 - 06:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Al these flags are set: JTRF BORF EXTRF PORF.

I find that quite hard to believe, unless your code is writing 1's to this register someplace.

Or maybe your code is running amok and writing stuff to I/O space. It >>is<< mapped to SRAM address space as well, after all. Rogue pointers in C have been a headscratcher for decades.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24261 View posts
Location: Melbourne,Australia
Posted by Kartman: Wed. Aug 1, 2007 - 01:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you suspect rogue interrupts are being enabled - have all unused interrupt vectors point to a 'catch all' isr and have it print out some diagnostics, or have separate isrs for all unused interrupts vectors and have them print out diagnostics. That will quickly prove/disprove your theory, then you can narrow down where the unused interrupt gets enabled.

Top