FreeRTOS with IAR on ARM Cortex

Hi Guys - Is there any special support implemented or needed for IAR’s library memory management (like #define configUSE_NEWLIB_REENTRANT)? How does IAR protect memory management from accidental reentrancy between tasks?
Best Regards, Dave

Have you seen this page? IAR’s memory allocation will only be used by FreeRTOS if you include heap_3.c in your application - in which case it is made re-entrant (rather crudely) within the heap_3 implementation. That does not protect the applications use of direct calls to malloc() though - try to ensure you only call pvPortMalloc() and vPortFree() in place of malloc() and free().

Thanks Richard as always! Of course if the IAR library internally uses malloc/free (as does newlib), then the user is hosed, no?
Best Regards, Dave

You can write your own malloc and free implementations that just call pvPortMalloc and vPortFree, so any uncontrollable calls to malloc just call pvPortMalloc, etc. Then you are safe.

Right, that’s the safe way, and IAR does support overriding library functions. Thanks again!

If IAR uses newlib, then there is a reasonable chance that they are using the newlib option to make malloc thread safe. One test is to make a very small program that just calls malloc and check the linker map. If the function __malloc_lock() is present, the option is available, and you can implement __malloc_lock() and __malloc_unlock() to provide the needed safety by having __malloc_lock disable the scheduler and __malloc_unlock re-enable it.

I’m not sure if there is a new lib option for IAR, maybe, but the compiler comes with its own optimised and scalable C library.

A quick check of the IAR web site shows IAR provide their own runtime library:

Yes, it looks like they have their own library, and there is a warning that some parts (like the heap allocations) are not thread safe. There is a comment about building a custom version of the library, so it may be possible to modify the library to make the heap (or other parts) thread safe.

link routed to page not found.
Please Can you share content or info or link again

So we are just starting a project with ARM, IAR, and FreeRTOS (ultimately to go to SafeRTOS), and I am concerned about inter-thread race conditions in general, and especially about malloc, free, new, delete, etc. The newlib library seems to have answers to these problems, but how does one get the IAR Embedded Workbench for ARM to use newlib instead of the library packaged with the IAR environment? I am just starting out on this project, and have been unable to find any IAR forum, so I am posting the question here out of some desperation.

@Moriah, Why do you want to use newlib, instead of IAR’s library? newlib provides facilities you seek but must be built with the proper options and using the target toolchain. Difficulties abound if newlib is not built with the correct options (as done by multiple microcontroller vendors and even ARM). If you must use newlib, contact IAR support to discuss…
Hope that helps!
Best Regards, Dave

No, we do not require newlib; but we do require a thread safe implementation for errno and malloc/free, among other things we probably haven’t even discovered yet. IAR hedges on errno, and FreeRTOS uses inhibition of context switching to protect and non-thread safe malloc/free implementation, so I am not very happy wioth the current situation. I would prefer to use IAR libraries, as we get proper support. We are working on a safety critical project in a regulated environment, so proper vendor support releives us of much grief, technical, regulatory, and legal.

As far as I can tell, the malloc_lock technique that Richard D. mentioned is not specific to newlib, so you should be able to use it. The test is very simple: Provide an implementation of malloc_lock(), set a breakpoint on it and run any app that uses malloc().

Just be sure to implement mallock_lock with a recursive FreeRTOS mutex.

Memory allocation is kept in the portable layer of FreeRTOS so you can implement it however you like. Safety applications I’ve worked on don’t permit any dynamic allocation at all.

AUTOSAR for C++14 permits both dynamic allocation and exceptions. A middleware package we are required to use as a standard interface to another middleware package is written in C++ and does use templates and exceptions, so we are trying to find a way to accomodate that. :frowning:

PS Yes, I have always used fixed size pools as a replacement for malloc/free in safety critical stuff, but the world is evolving.

The first versions of FreeRTOS only had memory pools as an option - but that proved too restrictive - especially as back then typically there was less RAM to play with.

If it’s acceptable to have short critical sections in the memory allocator then you could update heap_4 to remove the vTaskSuspendAll() and instead have short critical sections around the parts that touch the file scope variables (including the heap structure). For example, you would not need to enter a critical section until this line, and can probably exit the critical section again on this line - then re-enter when the new block is inserted into the list again - etc. etc. However that would leave interrupts masked for a non-deterministic amount of time - which is something FreeRTOS wouldn’t do normally - and is probably worse for you.

We have changed the cpu of choice for this project to the rt600. This means we have all kinds of fancy security features now. We would like to isolate the C++ stuff to its own little world and have a heap allocator of some sort there. It probably still has to be thread safe, but only for those threads in the C++ code. This means we will likely be using secure-zone and the mpu to isolate the C++ code. The C++ code uses dynamic memory and exceptions, but everything else in the system should be able to be staticly allocated at build time using the linker to declare sections for any memory pools needed, and managing those pools ourselves. We might be ale to override operator new in the C++ code to allocate from dedicated pools there also, but I don’t know enough about the details there. I suspect we will still need to support things like std::string and std::array and std::vector for that code, so variable length allocations and frees will probably be required.

What I am trying to do now, since we don’t have any real hardware except a very limited supply of dev boards using the rt600 (back ordered – supply chain usual fun…), is build a freertos system we can run some things with on the simulator.

I need to build a simulator environment the uses m33, secure-zone, mpu, and iar toolchain. There is a simulator environment that I will likely start with that uses the Kiel toolchain and the gcc compiler, but I couldn’t find a Makefile anywhere in the distribution for that demo, and I do not have access to the Kiel toolchain.

Can anybody suggest a way to use that kiel-ggc demo and convert it for the iar toolchain? That would be my preference.

I would even settle for a starting point that just used the gnu toolchain from a Makefile.