Out of memory - ERROR 401

[flauberttagu]

Hello community,

We have an issue when using NBBiometrics's fingerprint module on the K64. When the enroll feature is triggered, we immediatly have a 'Out of memory error 401' (images attached). The fingerprint module is initially build based on the STM32 were we found documentation. But the issue is completly different on FRDM K64 which is the module we are currently using.

We have no clue in what context does out of memory issue comes from. On k64f there is lot of plenty memory available to allocate, so not sure exactly. On k64f there is lot of plenty memory available to allocate, so not sure exactly.

Can someone help us to solve this issue.

Best regards.

[bobpaddock]

Not a lot to go on as Myke said.
As a pure guess I'd look at the linker script to see what it has for a heap size.  It is probably to small.

[myke_predko]

@flauberttagu 

Sorry, but you're going to have to provide a lot more information for anybody to help you.  

Could you please provide the model of the fingerprint reader (there seems to be several) as well as a pointer to the source for the library that you're using?  Along with that, what is the STM32 hardware (and firmware) that the example code is based on?  

[flauberttagu]

Dear Myke,

We finally had the help from our supplier. The issue was cause by the lack of heap memory required by the fingerprint module. In our implementation all required ressources was divided in stack and heap but we did not have enough ressources to trigger the feature because of the FreeRtos used.

-- Next Challenge -- We will try to find a way to increase the heap memory.

Unless you can give us an advice. Thank you for your previous answer.

Best regards.

[myke_predko · Accepted solution]

@flauberttagu 

The Heap (and Stack) size are defined in the "MCU Linker" section of C/C++ Build of your project Preferences.  

You'll probably have to look at your .map file to understand the actual amount of data devoted to the heap and what is available.  

Good luck!

[flauberttagu]

Dear @myke_predko 

Yes the heap memory is fixed. We try to find a way to not too much the heap memory with other tasks (if possible). This way we should avoid / solve this issue.

Thank you for your help.

Best regards.

[myke_predko]

@flauberttagu 

Are you running FreeRTOS?  If so, then you can very easily setup your heap size in FreeRTOSConfig.h  

If you're stuck at the 64k limits, you can increase the size of your SRAM_UPPER which is the primary SRAM resource to give yourself more space.  In 128k devices with SRAM_UPPER defaulting to 0x20000000 and SRAM_LOWER at 0x1FFF000, I change SRAM_UPPER to start at 0x1FFF0100 and set it's size to 0x1FF00 and change SRAM_LOWER's size to 0x100.  That gives you almost 128k of contiguous space in SRAM_UPPER without having to do anything unnatural.  

Now, some people don't like this because it crosses the SRAM bank boundary, but when increasing the SRAM_UPPER size was discussed earlier, it was revealed that there is only one case where this is a problem and that's a 64bit transfer that straddles both SRAM banks (the probability of that happening is infinitesimal and is zero if you don't use 64bit sized variables/structures).  

Hopefully that willl give you a couple of options for making more heap space available.  

myke

[flauberttagu]

Hello @myke_predko ,

Yes we are using a freeRTOS. About your advice "you can increase the size of your SRAM_UPPER which is the primary..." thank you very much. We will try to configure the solution this way and see what we can achieve. If you want, I will gladly tell you the outcome.

You are really helpfull. It is highly appreciate.

Best regards.

[ErichStyger]

To add on this: FreeRTOS has the ability to deal with multiple heap segments:

https://mcuoneclipse.com/2017/09/18/using-multiple-memory-regions-with-the-freertos-heap/

Therefore I would not go down the path combining the the memory segments into one: I'm using that Heap 5 on all the Kinetis devices with that dual memory controller and splitted memory map.

PS: the Heap 5 memory view is currently broken in 11.4.0, but that does not affect the functionality of the RTOS itself.

I hope this helps,

Erich

[flauberttagu]

Dear @ErichStyger ,

Thank you for your blog article :

Using Multiple Memory Regions with the FreeRTOS Heap | MCU on Eclipse

It is better to have multiple solution. In every case we learn. We can also adapt to many specific cases. We will look at your solution and see if we can adapt it to our issue.

Best regards.