xmega128a1u stackoverflow or what?[solved]

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

Hello,

I have a pretty large code and sometimes my code jump to first line main.c and  SRAM is empty at that moment but all ports and periphery  are still configured. The optimization seems help, but the problem occurs in any time, it could work for days without problem or the problem could appear after 10 minutes. I tried to change size of the buffers but it seems its not helping.

 

How to find that bug?  

 

UPDATE: I've found my bug, it wasn't a bug actually. I made a lot of changes for code optimization and it seems now I don't have stackoverflow.

the problem was that I have 6 spi devices, 2 gprs modules, several sensors, external flash memory, USB-cdc, so xmega stack was overloaded when I was getting too much data. So I don't know now what is the better option for me: moving form xmega to more powerful mcu or leave it on xmega and  hope for the best.

 

Thank you guys for your help, especially

1. Very powerful thing for monitoring stack  (Thanks mojo-chan ) here http://www.avrfreaks.net/forum/s...

2. Also thanks  gchapman for idea about static code analysis  Cppcheck found some bad moves. And I've never used data breakpoints before, with the canary algorithm it helped me a lot

 

Last Edited: Sat. Sep 9, 2017 - 07:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can monitor stack usage fairly easily. Just create code in .init that paints all unused RAM with a canary value and then periodically check what the lowest address between the top of RAM and the end of BSS is with that value.

 

However, this kind of reset can be caused by other things. A bad interrupt, corrupting the PC somehow, corrupting EIND causing a jump to unused flash and a wrap around to address 0 again, that sort of thing.

 

Again, you can try to diagnose it by putting some code in a .init section. For example you could try to dump some diagnostic data such as the stack pointer and upper few kilobytes of stack/RAM to try to determine where you came from.

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

Thank you, good ideas!

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

Hello SirLancevrot,

 

Check the "Cause of Reset" at the very beginning of your main.

 

Here is a link to Atmel Software Framework-based implementation/wrapper of it: http://asf.atmel.com/docs/latest/common.services.wtk.example2.xmega_a3bu_xplained/html/group__xmega__reset__cause__group.html

 

If you are not using ASF for some reason - it is still possible to get the reason of reset - check how ASF does it (which register do they check).

 

It should narrow down a list of reset sources you might be experiencing.

 

Let us know the outcome.

 

Regards

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

Most firmware's use a ms timer tick.

You can easily modify all interrupts to make a copy of that ms timer tick every time they fire and save it to the  .noinit section.

That will keep an up to date record of the last interrupt fired and you can dump those values after a reset.

For better resolution also read & save the timer register itself.

Or use a circular buffer for the last couple of 100's interrupts, but that's probably overkill.

 

I would probably go the route of lint & static code analysis.

It's often a runaway pointer.

The "const" keyword is your friend. (But a bit of a nuicanse to add everywhere to existing firmware).

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

SirLancevrot wrote:
The optimization seems help

Could you elaborate on that?

 

Almost invariably, if changing the optimisation setting breaks the code, it means there is a flaw in the code - the code is relying upon or assuming something that it shouldn't.

 

the problem occurs in any time, it could work for days without problem or the problem could appear after 10 minutes

Ah - intermittent problems are always the worst!

 

As the others have said, you need to instrument your code to get some insight into what's happening.

Also, log stuff that's available externally.

 

Can you send stuff to a serial port?

 

This will likely be an iterative process: start with the stack monitor and reset reason; possibly also the Event Log.

See what you can glean from these, and add further stuff as required.

 

Or use a circular buffer for the last couple of 100's interrupts, but that's probably overkill.

I would definitely start with the circular buffer - as you don't know how long it's going to run before the symptoms present 

 

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

0Pal wrote:

Hello SirLancevrot,

 

Check the "Cause of Reset" at the very beginning of your main.

 

Here is a link to Atmel Software Framework-based implementation/wrapper of it: http://asf.atmel.com/docs/latest/common.services.wtk.example2.xmega_a3bu_xplained/html/group__xmega__reset__cause__group.html

 

If you are not using ASF for some reason - it is still possible to get the reason of reset - check how ASF does it (which register do they check).

 

It should narrow down a list of reset sources you might be experiencing.

 

Let us know the outcome.

 

Regards

 

No, it defensively is not reset, because ports and periphery devices such as SPI for example are still configured

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

SirLancevrot wrote:
SRAM is empty

What do you mean by that?

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

awneil wrote:
What do you mean by that?

 

I mean that all my variables are empty or they have their initialization values 

 

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

SirLancevrot wrote:
all my variables are empty

They can't be empty - they must have some value!

 

But it sounds like you're saying that the 'C' runtime startup code has run - or, at least, the bit that initialises variables.

 

Can you leave a system (or some systems) running with the debugger attached, and a breakpoint set at the start of main() ... ?

 

What about all the other suggestions of instrumentation, logging, and static analysis?

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

If you do as I suggested and create some .init code, say in .init1, you can create a breakpoint immediately after the problem happens. You can also do it by using the disassembly view to set a breakpoint on the reset vector.

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

You don't have an exit from main() - do you ... ?

 

 

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

Paulvdh wrote:
I would probably go the route of lint ...
and assert

The Ganssle Group logo

The Ganssle Group

Automatically Debugging Firmware

by Jack Ganssle

May 2014

http://www.ganssle.com/dbc.htm

...

 

(next to last section)

Side Effects

...

... (you do use Lint, don't you? It's an essential part of any development environment) ...

...

There's a zero price lint in Microsoft Visual Studio Community.

Microsoft

MSDN

/analyze (Code Analysis)

https://msdn.microsoft.com/en-us/library/ms173498.aspx

Microsoft

Visual Studio

Compare

https://www.visualstudio.com/vs/compare/

(expand Advanced Debugging and Diagnostics)

 

"Dare to be naïve." - Buckminster Fuller

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

awneil wrote:

You don't have an exit from main() - do you ... ?

 

My code  looks like

int main (void)
{                   //my code jumps here and all variables look like it was reset,
 <----                   //but xmega is already configured: CLK, USB, Timers, UARTs, SPIs, I2C, ADC, all are configured
    setup();

    while(1)
    {
        func1();
        func2();
        ...
    }
}

ISR()
{

}

ISR()
{

}

ISR()
{

}

 

Last Edited: Wed. Sep 6, 2017 - 03:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:
If you do as I suggested and create some .init code, say in .init1, you can create a breakpoint immediately after the problem happens. You can also do it by using the disassembly view to set a breakpoint on the reset vector.

 

Yes, i'm waiting for that bug right now, and i'll put disassembler here

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

SirLancevrot wrote:

int main (void)
{                   //my code jumps here and all variables look like it was reset,
 

So, as previously stated, it sounds like your code is actually jumping to somewhere earlier than that - so that it does the 'C' startup RAM initialisation stuff

 

eg, the Reset vector ... ?

 

 

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

I've got this

I'm not good in assembler, so maybe somebody could find somthing

I also put a trap, if it would be reset PORTA.DIR must be 0

    while (PORTA.DIR==0xC0)
        {LED_BLUE_ON;}

Last Edited: Wed. Sep 6, 2017 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like your code is vectoring to address 0x0000 rather than the MCU being reset.  Does every enabled interrupt have an ISR defined?  If not, undefined ISRs cause a vector to 0x0000.

Greg Muth

Portland, OR, US

Atmel Studio 7.0 on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

This looks a bit unusual:

while (PORTA.DIR == 0xC0)
    {LED_BLUE_ON;}

What is changing the value of PORTA.DIR while this loop is looping?

Greg Muth

Portland, OR, US

Atmel Studio 7.0 on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

His theory is, I think, that after a proper (hardware) reset, PORTA.DIR would be zero; so, if it starts main and is non-zero, the problem (or its symptom) has occurred.

 

But dunno why he'd check for the specific value of 0xC0 - rather than just non-zero ?

 

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

awneil wrote:

His theory is, I think, that after a proper (hardware) reset, PORTA.DIR would be zero; so, if it starts main and is non-zero, the problem (or its symptom) has occurred.

 

But dunno why he'd check for the specific value of 0xC0 - rather than just non-zero ?

 

 

Yes you're are absolutely right, the 0xC0 is value what it has to be after setup

PORTA.DIR!=0 is the same

Last Edited: Wed. Sep 6, 2017 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SirLancevrot wrote:
PORTA.DIR!=0 is the same

Well, clearly not the same!

 

As you have "strange" behaviour anyhow, I'd think it best to just check for non-zero - not rely on just one non-zero value.

 

After all, if you catch it with a non-zero value other than 0xC0, you have gained an extra bit of information - haven't you?

 

 

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

awneil wrote:

SirLancevrot wrote:
PORTA.DIR!=0 is the same

Well, clearly not the same!

 

As you have "strange" behaviour anyhow, I'd think it best to just check for non-zero - not rely on just one non-zero value.

 

After all, if you catch it with a non-zero value other than 0xC0, you have gained an extra bit of information - haven't you?

 

 

Yes, in any case, thank you all, now I have some new ideas.

I'll write and update post when I find a solution

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

SirLancevrot wrote:
I'll write and update post when I find a solution

yes

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

mojo-chan wrote:
You can monitor stack usage fairly easily. Just create code in .init that paints all unused RAM with a canary value and then periodically check what the lowest address between the top of RAM and the end of BSS is with that value.
Might be possible to test the SP in the function prologue (test frame extent, create stack frame, call)

https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/AVR-Options.html#AVR-Options

...

-mcall-prologues

Functions prologues/epilogues are expanded as calls to appropriate subroutines. Code size is smaller.

....

https://gcc.gnu.org/wiki/avr-gcc?highlight=%28prologue%29#Frame_Layout

 

"Dare to be naïve." - Buckminster Fuller

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

mojo-chan wrote:
You can monitor stack usage fairly easily.
Indeed via a hardware debugger and XMEGA's two data breakpoints.

There can be a case of dis-continuous stack frames such that two data breakpoints would not be enough.

AVR simulator can have unlimited breakpoints but would need to stub I/O functions; those functions could be a source of the issue(s).

 

Atmel Studio

Stack Overflow Detection Using Data Breakpoint

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-A4FC8DB5-6B28-4893-93BA-7A4406698E5D

Atmel Studio

General Information on Data Breakpoint

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-CC67F575-4C06-4BD1-B5BF-44ED2142C215

(table)

Maximum Data breakpoint supported

Simulator

Using Simulator in Atmel Studio

Using the Simulator in a Debugging Session

http://www.atmel.com/webdoc/simulator/simulator.section.bld_gud_lc.html

...

  • Unlimited numbers of breakpoints regardless of device and OCD system limitations.

...

 

"Dare to be naïve." - Buckminster Fuller

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

Thank you all who commented this post. I've updated the top message

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

SirLancevrot wrote:
... moving form xmega to more powerful mcu ...
Choices ... choices wink

SirLancevrot wrote:
... or leave it on xmega and  hope for the best.
No need to hope.

XMEGA128A1U is a follow-on to mega1280; both have only 8KB of local RAM and an EBI (64KB for mega, 16MB for XMEGA)

64KB of external RAM can be attached via ports H and J.

XMEGA Xplained Pro has 512KB of RAM.

Stack can roll into or out of external RAM though it's not ideal for throughput; some AVR C compilers will have two stacks (AVR GCC is one stack)

XMEGA may be why it was selected due to

several sensors

XMEGA C has reduced analog performance than XMEGA A but XMEGA384C3 has 32KB of internal RAM.

A CPLD can be attached to an XMEGA to add I/O.

SirLancevrot wrote:
... about static code analysis  Cppcheck found some bad moves.
lint (cppcheck) is not much of a static analyzer.

lint plus C assert goes a long way for zero price; the cost is slightly more program space and lines of source code, and a slight increase in execution time.

PC-lint is commonly operated and about an order of magnitude less expensive than a full static analyzer.

C and C++ static analyzers can be effective once one learns how to operate it; the demand for C and C++ static analysis has lead to the creation of several analyzers (choices wink

A limited form of static analysis is stack usage analysis.

 


AVR1312: Using the XMEGA External Bus Interface

http://ww1.microchip.com/downloads/en/AppNotes/doc8058.pdf

via http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en592037

and http://www.microchip.com/wwwproducts/en/atxmega128a1u

http://www.atmel.com/products/microcontrollers/avr/avr_xmega.aspx?tab=documents

(pull-down menu, Application Notes)

...

AVR1312: Using the XMEGA External Bus Interface

AVR1312: Using the XMEGA External Bus Interface

AVR1312: Using the XMEGA External Bus Interface
(file size: 133875, 10 pages, revision A, updated: 06/2010)

(Software updated 09/2015. File size: 760KB)

This application note describes the basic functionality of the XMEGA EBI with code examples to get up and running quickly. A driver interface written in C is included as well.

...

(AVR1312.zip is missing)

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATXMEGAA1U-XPRO

http://www.microchip.com/wwwproducts/en/atxmega384c3

Gimpel Software

Gimpel Software

http://www.gimpel.com/html/index.htm

...

It [PC-lint] will thoroughly check your C/C++ source code for bugs, glitches, inconsistencies, non-portable constructs, and much more,  so you can find and fix your bugs more quickly, and more economically, than with traditional debugging procedures

...

GNATstack User's Guide

http://libre.adacore.com/developers/documentation-single/gnatstack-users-guide

https://gallery.atmel.com/?q=stack&orderBy=undefined&SelectedCategoryId=undefined

 

Edit : attempt at AVR1312.zip (source code)

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Sep 8, 2017 - 07:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SirLancevrot wrote:
1. Very powerful thing for monitoring stack  (Thanks mojo-chan ) here http://www.avrfreaks.net/node/33...

Access denied

You are not authorized to access this page.

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

SirLancevrot wrote:
1. Very powerful thing for monitoring stack  (Thanks mojo-chan ) here http://www.avrfreaks.net/node/33...

Access denied

You are not authorized to access this page.

 

 

My bad here the link http://www.avrfreaks.net/forum/s...

 

also there are no any stack extensions for AS 7, but i found code analyzer  for AS 6 https://gallery.atmel.com/Produc... (it was deleted but I think there is a copy somewhere on the Internet)

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

None of this thread makes any sense to me. I guess it might be because #1 has been edited? It says

SirLancevrot wrote:
the problem was that I have 6 spi devices, 2 gprs modules, several sensors, external flash memory, USB-cdc, so xmega stack was overloaded when I was getting too much data.
why would the STACK be "overloaded" with data? Are you saying that all your Rx buffers are stack frame autos? Why would you write code like that? Why not buffers in BSS? 

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

clawson wrote:

None of this thread makes any sense to me. I guess it might be because #1 has been edited? It says

SirLancevrot wrote:

the problem was that I have 6 spi devices, 2 gprs modules, several sensors, external flash memory, USB-cdc, so xmega stack was overloaded when I was getting too much data.

 

why would the STACK be "overloaded" with data? Are you saying that all your Rx buffers are stack frame autos? Why would you write code like that? Why not buffers in BSS? 

 

 

Maybe i'm wrong but let me explain my theory

 

I had a lot of fucntions which were called in while (1) and also I have a lot of UARTS, timer etc interrupts, so my stack was running low very fast. (at least canary algorithm showed to me that )

I've moved some functions from "always call" part, also I've realeased some SRAM, now it seems my resets are gone.

All my buffers are in BSS, It seems the problem was in a large amount of calls and interrupts

 

But now I've got new problem some of my variables is changing their value, but most of my vars are packed in structure together

If someone interested I could post whole my code here

 

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

Sorry are you the same person who started this thread? 

 

So were all your buffers previously stack frame automatics? 

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

sorry, I have to usernames it's a long story about my work and home computers

 

I can't get what does it means 'stack frame automatics'  my buffers is regular arrays and pointers

like uin8_t buffer[100];

or a structure with pionter

 

 volatile uint16_t lora1_fifo_data[LORA_B_SIZE][2];

 

fifo_t fifo_lora_buf1 ={
    .data = &lora1_fifo_data,
    .max_size = LORA_B_SIZE,
    .start_cell=5121,
    .end_cell=10240,    
};

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

"automatics" are non-static local variables.

 

https://en.wikipedia.org/wiki/Automatic_variable

 

Almost all 'C' compilers implement these on the stack.

 

So having large local buffers (arrays) is generally a great way to blow your stack!

 

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

no I almost do not have any local buffers, the biggest buffers are global

Last Edited: Sun. Sep 10, 2017 - 09:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Zaraam wrote:
But now I've got new problem some of my variables is changing their value, but most of my vars are packed in structure together
Possibly still a stack overflow.

Stack overflow overwrites static data

from

EmbeddedGurus

Are We Shooting Ourselves in the Foot with Stack Overflow?

Monday, February 17th, 2014

by Miro Samek

https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

...

 

A Shot in the Foot

...

 

A Smarter Way

...

 

How to Change the Default Order of Sections in RAM

...

But, may be an effect of the change in optimization.

 

Edit : But

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Sep 11, 2017 - 12:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

SirLancevrot wrote:

no I almost do not have any local buffers, the biggest buffers are global

Then I still don't understand why you thought this has anything to do with stack growth. Unless you use recursion it is VERY difficult to fill the stack with just the PUSH's and CALL return addresses of normal function nesting - you would need to be getting hundreds of function calls deep to get anywhere near risk using the stack UNLESS each such function was using large amounts of automatics - hence my question.

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

clawson wrote:
None of this thread makes any sense to me. I guess it might be because #1 has been edited?

 

@SirLancevrot: As Cliff suggests, it is really unhelpful & confusing to change the opening post - especially when people have already replied to it!

 

Instead, post updates as replies - so that the flow of the discussion is maintained.

 

Also, note that there is a 'Mark Solution' button on each reply to identify where & when a problem has been solved

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

Zaraam wrote:
I had a lot of fucntions which were called in while (1)

How would that give you stack overflow?

 

Having a lot of functions in a while(1) loop does not, in itself, cause a lot of stack usage: each function is called, then returns, before the next function in the loop can be called - so there is no "nesting" of function calls just because of the loop.

 

 

Quote:
I've moved some functions from "always call" part

What does that mean??

 

 

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

awneil wrote:
How would that give you stack overflow?
My point entirely. Sure if you have:

void function10() {
}

void function9() {
    function10();
}
void function8() {
    function9();
}
void function7() {
    function8();
}
void function6() {
    function7();
}
void function5() {
    function6();
}
void function4() {
    function5();
}
void function3() {
    function4();
}
void function2() {
    function3();
}
void function1() {
    function2();
}

int main(void) {
    while(1) {
        function1();
    }
}

Then by the time you reach function10() the stack contains nine return addresses (18 bytes). But if you are really talking about:

void function10() {
}

void function9() {
}
void function8() {
}
void function7() {
}
void function6() {
}
void function5() {
}
void function4() {
}
void function3() {
}
void function2() {
}
void function1() {
}

int main(void) {
    while(1) {
        function1();
        function2();
        function3();
        function4();
        function5();
        function6();
        function7();
        function8();
        function9();
        function10();
    }
}

there is never more than one address on the stack - so it only ever uses 2 bytes of stack space.

 

You are using a micro that has 8192 bytes of RAM!

 

It's true that if the code is really:

void function10() {
    char buff[40]
}

void function9() {
    int bigArray[140];
    function10();
}
void function8() {
    long longArray[30];
    function9();
}
etc.

Then because those variables are all stack frame automatics (they are created on the stack as the function is entered and removed when it leaves - hence "automatic" creation/deletion) the size of all of them would add up and add significantly to the overhead for RETurn addresses alone. But that's the only way to eat large chunks of stack space - you would either need both heavily nested functions each with moderately sized automatics. Or you would need just a few levels of nesting and some really huge automatics to get anywhere near using the whole 8K. Of course you could do it with:

void fuction() {
    char oneBigVar[8150];
}

int main(void) {
    function();
}

But doing that kind of thing on an 8K micro is never a good plan !

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

Hi guys,

tiny update: I've resolved all my problems with memory.

1. I found large local buffer (I didn't know that local buffers are located in the stack)

2.  My code is full of nested functions

3. I thought if Atmel Studio shows me  Data Memory Usage  :    7590 bytes   92,6 % Full It means that the everything is fine and we have enough memory for normal work.

 

Thank you again guys 

Last Edited: Tue. Sep 12, 2017 - 06:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SirLancevrot wrote:
I didn't know that local buffers are located in the stack

Again, it's automatics that are located on the stack; not all locals are automatic.

 

EDIT

 

See #35

Last Edited: Tue. Sep 12, 2017 - 08:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SirLancevrot wrote:
3. I thought if Atmel Studio shows me  Data Memory Usage  :    7590 bytes   92,6 % Full It means that the everything is fine and we have enough memory for normal work.
93% is scary full.

Recommendations :

  • stack high watermark dynamic test to obtain a warm fuzzy
  • static stack analysis to measure worst case stack usage

May be time to evaluate a 192KB or 256KB XMEGA AU as these have 16KB of local RAM; if that's a no go then shoehorn a 32KB SRAM via EBI onto the PCBA.

 

"Dare to be naïve." - Buckminster Fuller