Cannot access memory at address xxx, stack overflow management ?

I reduce my code footprint to 181kbyte program size / 1866kbyte stack+heap but I still have problems.

I had several time these messages :

"Previous frame inner to this frame (corrupt stack?)"

and/or:

"Cannot access memory at address @xxx", addresses are very close to the stackpointer.

"Execution is suspended because of error.

Watchdog has expired. Target detached."

...

Before trying to use a bigger memory (4Mbyte instead of 2) or deeply modify my code (no recursive call inside), I would like to have more informations about these errors. Sometimes they occurs after 1s and sometimes after 5mn with the same use. In debug mode with runtime_stack_checking enabled, I don't manage to identify the source of my problems (IDE messages are not each time the same).

Thanks for answers.

most of the errors are between StackPointer and FramePointer.

The Stack is growing downward, so a stack overflow should occurs in lower addresses ?

Thanks.

Stack overflow can be due to one of these:

- recursive calls (but you say you don't use them)

- a lot of nested calls

- big local variables, like arrays or structs

The more common is the last one. If this is your case, define these variables as static inside the function or as global variables.

You must also check heap: do you use it directly with malloc or calloc calls? or do you use OS or drivers which allocate a lot of memory?

Which kind of project is yours?

Hi Cris and sorry for replying late,

My project is based on a NiosII (fast, debug level1) hosted on Cyclone III on a custom board :

- The nios program / fpga firmware is stored in external flash (EPCS16)

- The code is executed in external 2MegaBytes sram (cypress cy7c1380d)

- Nios purpose is to manage external devices with SPI (2 SPI lines)

- A push&rotary button is used to modify some parameters used in SPI communications (it generates interruptions)

- these parameters are display on a LCD (onchip memory is used as a buffer between nios and LCD driver (vhdl))

- these parameters are stored in an external non-volatile memory (SPI FRAM)

A timer is used to manage parameters: update (if button interruption appends before), spi sending and display.

Most of the variable are global. The display routine is written is c++ and is quite complicated (I didn't wrote it, many vectors and objects are used to create the font and write the buffer). I have maid some tests with only the display routine in my nios, but there I didn't really find anything. The nios is more stable but I have 1 time the "cannot access..." error. So at the moment I am focused on hardware problems like checking sram timing (address setup&hold times)...

Do you know what is the exact meaning of "Cannot access memory at address" ?

Does it mean that the address is not reachable (hardware problem) or that the memory content is corrupted/not the one expected... ?

thanks again.

Are you sure the "Cannot access memory" message is not generated by your application?

Maybe in the code routines you didn't wrote. I'm not aware of such a message in standard Nios drivers.

Are you using a OS?

Anyway, before all you must be sure your hw is ok. So it's correct you now focus on checking timings, especially if the error appears randomly.

You can try loading a simple application which runs in internal memory and extensively test external memories data transfers.

It is quite hard to get a 'memory address fault' message.

The mmu fault handler for an OS might generate one.

The MPU interrupt handler might (if the MPU is enabled).

It is possible to enable a 'misaligned transfer' interrupt - whose handler might generate such a message.

If you try even harder (and are psychic) you can enable an interrupt for accesses to unknown addresses on the Avalon bus, but usually reads just return ~0.

Thanks for replies,

I am not using an OS and I am sure that this error is not generated by my code. The MPU handler is not enabled is my project. I found it only in some .exe file ("nios2-elf-gdb.exe" for example).

I have tested all the sram with an onchip memory application. The application looped for nearly 2hours without problem so I guess it is software problem. I am modifying an evaluation board to test my project, and especially the LCD routines.

Dear fates and cris72

now I met the same problem with you,I didnot have any idea to solve it,if you have any ways to solve the problem,could you give me some directions!

thanks and waiting for your reply,thank you.