Dave's FreeRTOS Helpers now on GitHub

Kernel
1

First, again thanks to Richard Barry and Richard Damon for all their help…

Due to popular demand, I’ve updated and placed a couple of components on Github: https://github.com/DRNadler/FreeRTOS_helpers, including:

  • heap_useNewlib (stop those nasty memory-management crashes), and
  • a port.c for Cortex M4-7 that adds MSP (ISR) stack checking

I’ve also updated and expanded the heap_useNewlib web pages.

Hope you find this helpful!
Best Regards, Dave

3 Likes
2

:+1:

[nothing to read here, just can’t post without 20 charaters]

3

Thank you @dnadler. This is a great contribution to the FreeRTOS community that I think will help a lot of people.

4

Dave,

Thank you for your contribution! Your page was very helpful to me. I am one of those unsuspecting embedded developers that got bit by sprintf using %f.

I’ve got heap_useNewlib_NXP.c running on Cypress PSoC 6 (M4). I’ve attached my linker script in case anyone finds it useful. I decided to give the heap all available memory:

__HeapLimit = __StackLimit - 1;
HEAP_SIZE = __HeapLimit - __HeapBase;

Then, I didn’t know how big it was, so I added this to heap_useNewlib_NXP.c:

size_t xPortGetHeapSize( void ) PRIVILEGED_FUNCTION {
    return (size_t)&HEAP_SIZE; 
}

so I can use this command:

> heap-stats
Total heap size:        57183
Free bytes in the heap now:     29919

Looks like I’ve got lots of room now. When I first switched, it seemed that newlib’s heap used more space than heap4, and I was already tight on space, so I had problems. Eventually I switched to newlib-nano supplemented with Marco Paland’s printf.

Thanks again, Carl

cy8c6xx7_cm4_dual.CK3.zip (3.9 KB)

EDIT: I should have mentioned that I am running with newlib version 3.3. I get the warning, but it seems to work fine.

1 Like
5

Do you expect the STM32 heap implementation to play nice with FreeRTOS+TCP and related Network Interface driver?

6

@orangesalad: I don’t understand your question. heap_useNewlib works with any GCC-newlib applications. Heap implementation from ST has bugs.

7

I am referring to the note in the readme of the FreeRTOS TCP stack. It states:

“At this time it is recommended to use BufferAllocation_2.c in which case it is essential to use the heap_4.c memory allocation scheme”

8

The comment is either not complete or maybe a bit misleading.
Thread-safe newlib heap allocator also plays nicely with BufferAllocation_2.c, of course.
When it comes to special cases like using dynamic non-cachable memory for some purposes, but cachable for others, things might get more complicated. If this applies to your MCU at all.

9

Sorry for my ignorance, but could you expand a bit on the scenario with mixed cacheable and non-cacheable memory? I believe the STM32F7 part has an L1 Cache and some RAM is cached while other is not, so I guess this caveat could be applied to that part?

10

When DMA accesses physical memory, it bypasses the caching mechanisms.
So if cached memory is used, the driver must flush and refresh the memory sections before they can be accessed.
The STM32F7 driver likes to assign uncached memory to be used by DMA. Therefore, I prefer to use BufferAllocation_1.c, so the allocation is under our control ( and not the heap ).

11

As Hein explained it’s all about DMA based drivers. You have a number of options as disable caching completely and nether mind manual cache management or use caches and dedicated buffers from non-cached configured MPU regions for DMA drivers along with cached memory for normal heap or enable caching completely and take care about cache management in your DMA powered drivers.
It depends on your use cases / requirements.
For FreeRTOS TCP including the STM32F7 driver you should follow Hein’s advise b/c he’s the creator :+1:

12

Yes, this is a clumsy comment, and a good example of why you shouldn’t write things that go out of date in comments.