Dynamic Memory Usage

[sarraciro]

Posted on December 04, 2013 at 12:23

Hi guys,

I have to do a RAM check routine that performs Class-B controls on pre-assigned (probably all RAM) memory block.

The first doubt that rise is :

if I allocate the memory statically I can't free it (or release them, as you prefear) at the end of the tests, right?

if I define a memory section in linker script I can't release them at the end of the tests, right?

I think that dynamic allocation can be usefull (may be more complicate to implement...).  The problem of fragmentation of data, cause of resources releasing, can introduce several troubles.

Has anyone

addressed this issue

in some

previous

experience?

Thanks &

Regards

#dynamic-memory-usage #embedded

[Andrew Neil]

Posted on December 04, 2013 at 19:16

But Dynamic allocation just comes from the Heap - and you can't ''release'' that, either!

Does this ''RAM test'' have to be done while your main code is running, or can it just be done once as part of the ''startup''...?

[sarraciro]

Posted on December 05, 2013 at 01:56

The test have to run both at startup and as periodic task

[sarraciro]

Posted on December 05, 2013 at 02:14

I found this interesting notes about this topic...

There are several alternative to

malloc()

:

Block memory allocation: the allocation of memory in fixed size blocks. one or more pools of memory blocks are defined; Multiple pools facilitate a choice of block size.

Of course, there is still the possibility that an allocation will fail because there are no further blocks. However, this is entirely predictable and hence, can be mitigated.

Reimplementing malloc(): Another creative way is to use block memory services to implement

malloc()

. The simple approach is to implement a series of block memory pools with sizes that are powers of two – maybe 16, 32, 64, 128 bytes, for example. It is then a simple matter to code

malloc()

so that a block which is large enough for the requested memory is allocated.

Fixing fragmentation: Putting aside the problems of timing and resource exhaustion, there are ways to solve the problem of memory fragmentation while allowing

malloc()

to use a conventional heap... like address fragmentation using a garbage collector. From time to time, when a memory allocation is attempted, the garbage collection routine is run, which moves all the allocated blocks of memory around so that the free space is in a single contiguous block. However, garbage collection has two major downsides: Memory allocation becomes very non-deterministic, as it is not possible to predict when the garbage collector will be run or how long it might take.

Colin Walls released an interview in which he declared:

''The word “dynamic�? should – and normally does – ring alarm bells with embedded software developers. The dynamic allocation/creation of anything is fraught with problems in real time and deeply embedded systems, so, wherever possible, static alternatives should be considered. Dynamic memory allocation is a good example of where this caution is wise, but a clear understanding of the issues can lead to implementations that are fit for purpose.''

Regards

--

RC

[sarraciro]

Posted on December 05, 2013 at 02:41

I

mho

for the use of Heap area (defined in linker script) would be enough:

void* __attribute__((__section__(''._user_heap_stack'')))TestRAMFunc(void){}

Regards

[Andrew Neil]

Posted on December 05, 2013 at 08:09

''Colin Walls released an interview in which he declared''

Can you give a full reference for that?

''The word “dynamic�? should – and normally does –ring alarm bells with embedded software developers. The dynamicallocation/creation of anything is fraught with problems in real timeand deeply embedded systems, so, wherever possible, static alternativesshould be considered. Dynamic memory allocation is a good example ofwhere this caution is wise, but a clear understanding of the issues canlead to implementations that are fit for purpose.''

Amen!

 

Imho for the use of Heap area (defined in linker script) would be enough:

 

void* __attribute__((__section__(''._user_heap_stack'')))TestRAMFunc(void){}

 

 

But then you'd only ever test the Heap area - no other RAM would ever get tested!

In particular, the Stack would remain untested...

[frankmeyer9]

Posted on December 05, 2013 at 10:15

The Cortex M does not have an MMU, hence your memory layout is always static.

The *alloc() and free() functions are rather a clib portability layer, and may seem to obscure that fact.

[Andrew Neil]

Posted on December 05, 2013 at 11:23

It's still not clear (to me, at least) what problem it is that you think dynamic allocation will actually solve.

Initially, your concern seemed to be about static allocation and not being able to ''release'' blocks of memory. As discussed, the Heap (from which memory is dynamically allocated) is, itself, statically allocated - so I still don't see how it's going to help?

[sarraciro]

Posted on December 05, 2013 at 11:59

The task that I try to solve is write a function (or better a set of functions) that perform some memory check.

Actually I'm working on RAM test. This test have to run at start up and periodically while the system is on-running.

For now, suppose we need to allocate and want to use a 1 KB chunk of memory, we'll test it using the Checker Board test before we use it to make sure there is no problem with the chunk of RAM we selected (this test is destructive). After that we have to allocate and want to use a 2 KB chunk of memory (other test). And finally we allocate and want to use a 2 KB chunk of memory  to make sure that both the allocated RAM and the stack space are ok.

The tests would be executed on all RAM space. Thus I

thought about dynamic allocation, for change the chunk in which the test work.

I hope that clarify the purporse of the task.

Regards

[dthedens23]

Posted on December 06, 2013 at 20:12

read AN3307

one can request a class B library from ST sales office.