I'm using two open source modules in a project, an MP3 decoder and a
TCP/IP stack. Long story short, the TCP/IP stack contains a "static
struct" that holds the ARP table, and parts of it are being overwritten
when the MP3 decoder gets its chance to run.
I'm at a loss because I can't understand how the compiler would allow
this to happen. There is a line in the .map file that lists the struct
that is getting overwritten:
.bss.arp_table
0x20000ea0 0x60 ./uip-1.0/uip/uip_arp.o
Wouldn't this indicate that this section of RAM is set aside for
arp_table and won't be freed during execution? The problem occurs
everytime, very reliably. It's like variables in the MP3 decoder are
assigned to the same RAM address.
Any advice on tracking down this problem? This is running on a
Cortex-M3, by the way.
Additional information about this problem: I have confirmed that when entering a function, the data passed into the function, or variables local to the function are being allocated in this section of RAM that has already been allocated to a static struct. What on earth could cause this problem?? I'm using CodeSourcery G++ Lite.
A stack overflow ? It would be a good idea to post the map file and the linker script.
Giovanni Di Sirio wrote: > A stack overflow ? > > It would be a good idea to post the map file and the linker script. This problem started occurring when I added a function that would make heavy use of the stack, so that might be my problem. As I was looking through source files, I came across the stack allocation, and it's only 256 bytes; probably not enough. I used a sample project to get started so I don't fully understand how this sets the stack. #ifndef STACK_SIZE #define STACK_SIZE 64 #endif static unsigned long pulStack[STACK_SIZE]; It's obvious this makes the stack 64 32-bit words long, but the only other instance of pulStack is where the vector table is set up. How exactly does the linker know to use this space for stack? If I remember correctly, the stack is populated from the top, down? If this is the case, this makes sense because the struct that is being corrupted is very close to the bottom of the stack. Is there a good way to determine the required stack size, or is it not an exact science?
I cannot answer, it depends on how the startup file and the linker scripts are done and the stack you are running on (process or exception). The linker does its work by executing a linker script, usually it has a .ld extension but may change, you should have one in your project, it is specified in the linker command line. Anyway, just try to increase that value and see if something change.
Giovanni Di Sirio wrote: > I cannot answer, it depends on how the startup file and the linker > scripts are done and the stack you are running on (process or > exception). > > The linker does its work by executing a linker script, usually it has a > .ld extension but may change, you should have one in your project, it is > specified in the linker command line. > > Anyway, just try to increase that value and see if something change. Thanks for your suggestion. That fixed the problem.