Hardfault in freeRTOS MTU Exchange (MTU>=200)

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Susheel Nuguru — Fri, 04 Oct 2019 05:39:01 GMT

Just figured that the issue with increasing the MTU size to 247 could be too little stack size when creating the Timer thread.

Please look at this thread for a possible workaround.

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

ilw — Wed, 15 May 2019 16:56:11 GMT

I had the same symptoms/problem as Dave (i'm using v15.0 of the SDK) and i just thought i'd post to say that increasing the task stack depth/size in nrf_sdh_freertos.c from 256 to 512 solved the problem for me.

It looks like even the latest version (15.3) of the SDK still has a stack of 256.though, so i guess Dave's problem must have been slightly different in some way...

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Susheel Nuguru — Mon, 02 Jul 2018 19:48:22 GMT

Hi Dave,

Did you manage to solve this issue? Just curious to know what caused this if you already know the answer.

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Susheel Nuguru — Mon, 18 Jun 2018 07:56:39 GMT

nope, do i need to? but after reading your reply 5 days ago, seems that i missed to see that you are using GCC compiler, I tested with keil 😞

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Dave_couling — Thu, 14 Jun 2018 07:34:05 GMT

did you change the nrf_ble_sdh_freertos task size?

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Susheel Nuguru — Thu, 14 Jun 2018 07:30:51 GMT

i did not get any hardfault .. when i changed those two macros. I tested this on hrs freertos example on SDK15. what am i doing wrong(or right?)

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Dave_couling — Wed, 13 Jun 2018 18:05:00 GMT

I set the linker file to:

RAM (rwx) : ORIGIN = 0x20002d88, LENGTH = 0xC8E8

After initializing the stack the ram_start shows I could reduce the App RAM start to 0x20002CC0

Also in FreeRTOSConfig.h

configTOTAL_HEAP_SIZE ( 28000 )

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Susheel Nuguru — Wed, 13 Jun 2018 06:37:47 GMT

I would have thought that this is FreeRTOS stack corruption, which is most likely too little stack size left for either app or freertos. How much RAM was left for the app overall?

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Dave_couling — Sat, 09 Jun 2018 21:00:12 GMT

I tried increasing the size of NRF_BLE_FREERTOS_SDH_TASK_STACK to 4096 and even moved the definition of this to FreeRTOSConfig as it makes more sense to control it there. However I still the same hardfault with the follow BLE settings:

NRF_SDH_BLE_GAP_DATA_LENGTH 251

NRF_SDH_BLE_GAP_EVENT_LENGTH 6

NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

Is there any guide for both setting these parameters and adjusting RAM allocation accordingly?

RE: Hardfault in freeRTOS MTU Exchange (MTU>=200)

Austin — Sat, 09 Jun 2018 06:15:36 GMT

This seems like a classic stack overflow symptom. Try increasing the size of the FreeRTOS stack used to handle SoftDevice events in nrf_sdh_freertos.c.

Events from the SoftDevice are polled in nrf_sdh_ble.c. Each event is retrieved into a RAM buffer allocated on the stack prior to handling. As you increase NRF_SDH_BLE_GATT_MAX_MTU_SIZE, the size of the buffer on the stack required to receive events from the SoftDevice also increases.

The default NRF_BLE_FREERTOS_SDH_TASK_STACK size is 256, so as your MTU approaches that limit, the buffer required during event handling is likely spanning over the the allocated task stack, resulting in a stack overflow.

Although not always reliable, it's probably a good idea to turn on stack overflow detection within FreeRTOS.

It would be possible to add a compile time check in nrf_sdh_freertos.c which reports an error when the MTU is too large for the allocated stack. The stack size needs to be larger than the MTU to allow for event handler function calls and their stack usage.