Problem with pointer on ARM Cortex M4 and error message no source available for ''''

Posted on July 18, 2013 at 10:57

Hi,

I check with a flag variable in STMStudio and the problem really comes from the micro controller.

If I create a vector of a size too large, for example 256 float32_t, the loop to fill this vector is omitted and I have a HardFault Interruption...

Error accessing memory address 0x0

 

Indeed in my functions, all variables address are set to 0x0 and all my variables are to 0. So, there is a memory problem.

I don't understand theses memory problems because I don't overflow the memory ????

Thks for your help !

Posted on July 18, 2013 at 13:49

the problem really comes from the micro controller...So, there is a memory problem.

 

The micro just does what you instruct it to do, I'm not convinced that the problem isn't with the tools (compiler/linker). What does the .MAP or .LST file indicate about the created code?

Does the tool chain come with any working example projects you can test independently of your own code? Perhaps there is a problem with how your project is set up, or the start up code?

There is very little support here of CooCox, as mentioned they do have a forum of their own.

Try using Keil or IAR evals

For more assistance here you might want to post a complete example of what you're doing. Be aware that exiting main() will likely cause a fault.

Posted on July 18, 2013 at 17:09

When I declare my tables with the keyword static I dont't have anymore the HardFault interruption. But the ''No source available for '''' '' is still there...

Can you explain me why the bug seems to disappear by using static variables ?

I will try an example yes.

Thks.

Posted on July 18, 2013 at 18:46

Can you explain me why the bug seems to disappear by using static variables ?

Your stack is inadequately sized for the locals/automatics you're attempting to allocate?

Posted on July 19, 2013 at 09:14

@rocketdaw

Which code, soon as declare a table with a too big size, I have HardFault Exception... The code takes hundred lines, but the initial bug refers to this table... Don't need to post any code.

I just want to know how to deal with this problem.

@clive1

Thanks for help, what do you mean by ''your stack is inadequatly sized...'', I am quite a new in micro controllers field.

Thanks.

Posted on July 19, 2013 at 11:06

Local variables are stored on a stack, if the stack is designed to hold 1024 bytes you can't define an array that takes 8

From startup_stm32f4xx.s in Keil
; Amount of memory (in bytes) allocated for Stack
; Tailor this value to your application needs
; <
h
> Stack Configuration
; <
o
> Stack Size (in Bytes) <
0x0-0xFFFFFFFF:8
>
; </
h
>
Stack_Size EQU 0x00000400
AREA STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem SPACE Stack_Size
__initial_sp

void test1(void)
{
double array[1024]; // takes 8192 bytes of stack
// do something with array
}

void test2(void)
{
static double array[1024]; // takes 8192 bytes of preallocated RAM
// do something with array
}

Posted on July 19, 2013 at 11:47

Ok, good !

So, I just need to redefine this stack size ? Are they counter-argument to redefine it ?

Thks.

Posted on July 19, 2013 at 12:35

I'm going to assume you come from a PC programming perspective, where the stacks are bottomless, and you can malloc vast tracts of memory.

Embedded is constrained, dynamic memory allocation is generally avoided due to the potential for leakage and fragmentation of the heap. In interrupts things like malloc/free should be avoided due to the safeness of doing so, and the potential the allocation might fail and what you'd do then.

The stack is useful for things that would normally be dynamically allocated and freed across a call, transient stuff. You should pick a stack depth which accommodates your requirements for your maximal call tree. You should probably keep a running total in your head about how large it should be, although you can get static analysis tools to give you a number, a more practical approach is the mark the stack with a pattern, and then observed the low water mark in normal usage. The stack offers an always successful dynamic allocation, provided you don't below out the bottom of it. The goal isn't to make the stack stupid large, as it is to make it sufficiently adequate.

When you use ''static'' you are making a hard allocation against available RAM that the linker will divvy up, this is a limited resource and isn't shared amongst many routines. If you can partition the usage then consider a global allocation which multiple routines can share while not interfering with each other.