Char array of 1024 causes incorrect behaviour

[rowangee]

Posted on January 05, 2014 at 18:36

Hi,

We have a simple bit of code simply turning on an LED, however when initialising a char array of 1024 anywhere in the code the project is still built, but fails to enable the LED (or anything else, but we've stripped it back to the simplest code possible for debugging). If the array is reduced to 512 in size, everything works as expected.This is being built in CoIDE (win8) and the ARM GNU GCC compiler v4.7 on an STM32F103RBWhen compiled under linux (ubuntu) with eclipse and the same compiler it works as expected (with the 1024 array). This makes us suspect a memory mapping issue?Unfortunately we need to get it compiling under windows, and working around it by using smaller arrays would be awkward - any ideas?

[frankmeyer9]

Posted on January 05, 2014 at 19:25

Sounds suspiciously like a stack size problem.

Stack size is an item of the linking stage, and not dependant of the toolchain. It is usually defined as a project property, while default values differing wildly between toolchains. Increasing it will probably resolve the issue. However, as (preferred) alternative, you could allocate larger arrays/items as non-automatic variables, to avoid loading the stack.

[i_]

Posted on January 05, 2014 at 21:39

Thankyou for the quick reply fm,

Clearly I will have to do some reading on this, having just graduated from AVRs some of the bits are new to me.

[Tesla DeLorean]

Posted on January 05, 2014 at 21:48

Review the linker scripts and map files.

Consider the placement, and size of the stack/heap, and where these problematic variables are being allocated from. Understand the failure, are you getting a Hard Fault, what instructions are faulting, and what are the registers at this point?

[Andrew Neil]

Posted on January 07, 2014 at 01:01

''having just graduated from AVRs some of the bits are new to me''

Which bits?

The issue of stack overflow due to excessively-large automatic variables is the same for any platform which uses the stack for auto variables (which is nearly all of them).

[Tesla DeLorean]

Posted on January 07, 2014 at 02:36

Yeah, I think it's the bit about the guy behind the curtain now having a big cattle prod, and who comes out and zaps you now if you do something stupid.

It's the same experience a lot of x86 DOS/C coders had when their apps recompiled for Windows or 386 DOS Extenders started to throw faults all over the place. When the hardware starts catching where you inappropriately touch memory, or dereference NULL pointers, you have to get a lot more precise with the details. Gross failures, however should be pretty simple to nail down.

[frankmeyer9]

Posted on January 07, 2014 at 10:45

Gross failures, however should be pretty simple to nail down.

With a stack lingering at the limit and asynchronous interrupts, it is very likely to produce seemingly random crashes at differing code positions. For the unexperienced, this may take hours or even days to discover.

[Tesla DeLorean]

Posted on January 07, 2014 at 11:06

The OP has done a good job confining the issue, but the presented case lacks the code/context to understand the WHY portion of the problem.