Cause of ramdom errors in GCC with Mega644

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello to everybody,

I have a big project using a ATMega644 that when compiling GCC says...

Program: 58872 bytes (89.8% Full)
(.text + .data + .bootloader)

Data: 3833 bytes (93.6% Full)
(.data + .bss + .noinit)

EEPROM: 69 bytes (3.4% Full)
(.eeprom)

The program uses one external interrupt, and RTC, a Dataflash memory, the internal EEPROM, a LCD display, and Flash to store images and it has more or less 40 files between .C and .H.

The optimization is set to -Os.

I have found several ramdom errors when writing to the dataflash, specially with global variables that change their contents during the program, and without being "touched" by the program.

Can anybody point me things to check ir order to find this error, or anything that may help?

Thanks very much!
Ezequiel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ezequiel.aceto wrote:

Data: 3833 bytes (93.6% Full)
(.data + .bss + .noinit)

This leads to a strong suspicion that your data might be overwritten by stack.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I though about it. How can i mesure the stack size? I tried removing call to subfunctions by using inline or avoiding having long nested calls... I think I will have to reduce the ram usage more...
Any other hint?
Thanks!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well first off have you all your "const" data in PROGMEM? If not it could be that (especially text strings) that is eating all your .data space.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ezequiel.aceto wrote:
How can i mesure the stack size?
If the code flow is not too complex (recursive functions, function pointers ...), then you can try this tool:
http://www.mikrocontroller.net/attachment/55377/stackview.zip
Stu made a English translation of the German README:
https://www.avrfreaks.net/index.p...

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can initialize the "unused" SRAM at the end of the heap with a known constant (like, 0xdead) and at lots of points in your code, check the space that the stack has munched on these constants...

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[TUT] [C] GCC and the PROGMEM Attribute - how to store strings and constants in program flash instead of SRAM.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any way to set the stack size? So when the stack is overflow the AVR gets reset and I can detect a point where the stack overflows easily.

What about declaring the variables volatile, or static, or volatile static, does that helps to organize RAM?

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What about declaring the variables volatile, or static, or volatile static, does that helps to organize RAM?

Only a bit - it's possible that by making something (that doesn't need to be) not a volatile when it mistakenly is that it may never need to exist in SRAM so you might save the odd byte.

But can you confirm that you have read and understood the PROGMEM thing? In a program that is 58K with 3.8K of RAM usage it could easily be that 2K+ of the RAM usage is a waste if PROGMEM has not been used.

If you use:

printf("Hello world");

it uses 12 bytes of your precious 4K of SRAM. While if you use:

printf(PSTR("Hello World"));

no SRAM is used. PSTR() is just one form of PROGMEM - see the link Stu gave.

OTOH you may be an old hand at the Harvard programming game and know all about PROGMEM and the difference between const data/strings in RAM and flash in which case just tell us all to "shut up".

If you really understand the PROGMEM thing and you still have 3.8K used then try running a timer interrupt that samples SP each time and if below a certain threshold (0.2K from the end of RAM) then have it force a lock up/reset/debug message.

Cliff

Last Edited: Tue. Nov 24, 2009 - 04:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will change the way I'm declaring fonts and graphics, and will see how it works. Thanks very much.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ezequiel.aceto wrote:
Is there any way to set the stack size? So when the stack is overflow the AVR gets reset and I can detect a point where the stack overflows easily.
No. That would require hardware support not present in 8 bit AVRs.

You can arrange a fast timer interrupt to read the SP and keep a record of the minimum value it encounters. Add to that the stack usage of your most stack-hungry ISR and you have an idea of the maximum stack depth.

Or you can look at the memory window in the debugger. At the start of the program it is pretty easy to see your (maybe initialised) globals, and you'll soon get used to seeing stuff appear on the stack as you step through function calls etc. Soon you'll know if you have a stack overflow.

Quote:
What about declaring the variables volatile, or static, or volatile static, does that helps to organize RAM?
Declaring local variables static and/or volatile will probably result in increased RAM usage. Declaring global variables static and/or global will probably have no effect on RAM usage.

Large initialised local arrays are a common culprit of excessive RAM usage. Also, variadic functions (eg printf, scanf) called with lots of parameters gobble stack very quickly.

Christopher Hicks
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff wrote:
While if you use:

printf(PSTR("Hello World"));

no SRAM is used. PSTR() is just one form of PROGMEM - see the link Stu gave.

Isn't the proper procedure to use printf_P?
printf_P(PSTR("Hello World"));

Printf_P expects a pointer to a PROGMEM constant as its first parameter.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh sorry, thought I typed the _P, my bad.