Linker gets out of DRAM using FOTA and FreeRTOS

I create an app based on the peripheral_server_hid demo application. I sucessfully included FOTA and tried to include FreeRTOS now. This would ease my necessary business logic. With my first attempts to compile and link, I ran into a OUT OF RAM problem. The linker demanded 2000 bytes more of RAM.

So I had a look into the SECTIONS.LD (the FOTA version, as suggested in the application note on how to integrate FOTA into your own application) and the generated MAP file. It looks like the LD files starts to locate RAM of my app starting at 0x2000352C instead of 0x20000000. This is caused by the __app_ram_start defined somewhere.

This means, more than half of the precious 24K of DRAM are not available for my application. So I have the following questions:

  1. is this observation correct and because of the necessary FOTA lib?

  2. Does this mean, FOTA plus FreeRTOS are not possible, even with a small application?

  3. There is the DRAM_DSP with double the amount of RAM completely unused so far - according to the MAP file. How can I make use of it? I tried to put some of the DRAM sections into DRAM_DSP instead, but the application runs into an HARDFAULT in this case.

Any help appregiated

Michael

hm?! Nobody running into the same problem when combining FOTA and FreeRTOS? How do you do it?

So far it is really a killer for my project that I can not use FreeRTOS with a FOTA application.

ANY HELP OR ADVISE APREGIATED!

Michael

@mschmidl

sections.ld

Please try to change the memory allocations in the sections.ld file for the target sample application from:

to this modified file:

This change has been verified in peripheral_server sample code. It works.

Could you please verify on your side?

Hi Martin,

increasing the DRAM section by reductng the DRAM_DSP works. But this leads to more questions:

  1. Why not increase the DRAM section to even more and reduce the DRAM_DSP section to ZERO? I can not find any hint in the MAP file that anyone is using the DRAM_DSP section.

  2. What’s with the lower 13K of RAM so far unusable because the 0x2000352C defined by __app_ram_start ? Who is defining this constant? Is this because of the FOTA library?

  3. With the vThread_BLE() task, the bluetooth part works as expected now. But the Sys_Fota_StartDfu(1) function call has no effect now. How to entery FOTA when using the FreeRTOS in my application?

See a screenshot of the current vThread_BLE() task for detail:

@mschmidl
A1. You can use all DRAM_DSP space for normal application.
A2. 13KB size is used by FOTA library. You can look at the fota.map to confirm.
A3. If you do not use FreeRTOS, does it work or not? We need understand if this issue is caused by Free RTOS.

Can you provide your project so we can reproduce the issue?

Regarding 13KB size, almost 12KB can be reused by your BLE application. FOTA (library) is actually Bluetooth Low Energy stack with DFU feature.

If you need BLE application like in your project, that area (13KB) can be used.
That does not mean that DRAM size available for you is only 24kB-13KB =11KB. It is still around 24KB DRAM.

@mschmidl Were you able to get it to work with FreeRTOS?

I am having the same issue where FOTA worked without the FreeRtos but after including FreeRtos Sys_Fota_StartDfu(1) give me error SIGTRAP.

Are there any issues for using FreeRtos and FOTA together?

finally I got rid of the FreeRTOS idea. The RSL10 provides way to less RAM to use FreeRTOS in a decent way. You will run into OUT OF RAM problems very quickly.
So I stayed with the built-in “scheduler” even it is no real scheduler as you would expect when you know FreeRTOS e.g.

Thank you for your reply. We are in need to use the FreeRTOS and I am not sure how to resolve this issue.

Hi Martin,

Any suggestion on how this issue could be resolved?

Thank you.

not really. I’m considering using other Bluetooth modules from a different vendor in the future. I got this project running finally without FreeRTOS, but for future projects I’m unsure RSL10 is the right choice.

Hi @krishnaD,

We have looked into this issue further and believe we have a fix for the hardfault you are seeing. The requirements to implement the fix are listed below:

  1. Follow the steps in this topic to allocate 8kB of the DSP DRAM (40K) to the standard DRAM (32K). This is necessary to ensure the freeRTOS heap does not corrupt any of the Stack.

  2. Add the following header file include and lines of code to any location in which you call the ‘Sys_Fota_StartDfu()’. By default, this function will be called within the BLE Thread main loop (for manual button controlled updates), and also in the ‘ble_dfus.c’ RTE file message handler (for BLE controlled updates).
    The ‘OS_Tick_Disable()’ function will disable the Sys Tick interrupt, which can cause problems when switching to another firmware image.

#include "os_tick.h"
    OS_Tick_Disable();
    Sys_Fota_StartDfu(1);