Stack overflow?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 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.

  • 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

  • 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

  • 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).

  • 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

  • 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?

  • 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.

  • 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.

  • 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.

  • 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.