• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Subscribers 66 subscribers
  • Views 5534 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235879
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ble_app_hrs_freertos Increassing MTU Fatal error

Salmat

Hi,

Using SDK 15.3.0 , example "ble_app_hrs_freertos", pca10040 with armgcc.

I want to increase MTU and GAP data length.

I started with MTU to 247, and when I try to connect, on log :

<debug> nrf_sdh_freertos: Creating a SoftDevice task.
<info> app: HRS FreeRTOS example started.
<debug> nrf_sdh_freertos: Enter softdevice_task.
<info> app: Fast advertising.
<error> hardfault: HARD FAULT at 0x0002C004
<error> hardfault:   R0:  0x20008214  R1:  0x002A821C  R2:  0x20008214  R3:  0x20008208
<error> hardfault:   R12: 0x00000000  LR:  0x0002AAF1  PSR: 0x8100020E
<error> hardfault: Cause: Data bus error (PC value stacked for the exception return points to the instruction that caused the fault).
<error> hardfault: Bus Fault Address: 0x002A8228

The modifications I have done to the code are :

diff --git a/config/FreeRTOSConfig.h b/config/FreeRTOSConfig.h
index ae2167d..6dee317 100644
--- a/config/FreeRTOSConfig.h
+++ b/config/FreeRTOSConfig.h
@@ -63,7 +63,7 @@
 #define configTICK_RATE_HZ                                                        1024
 #define configMAX_PRIORITIES                                                      ( 3 )
 #define configMINIMAL_STACK_SIZE                                                  ( 60 )
-#define configTOTAL_HEAP_SIZE                                                     ( 4096 )
+#define configTOTAL_HEAP_SIZE                                                     ( 8192 )
 #define configMAX_TASK_NAME_LEN                                                   ( 4 )
 #define configUSE_16_BIT_TICKS                                                    0
 #define configIDLE_SHOULD_YIELD                                                   1
diff --git a/pca10040/s132/config/sdk_config.h b/pca10040/s132/config/sdk_config.h
index 8edaaed..715d28d 100644
--- a/pca10040/s132/config/sdk_config.h
+++ b/pca10040/s132/config/sdk_config.h
@@ -39,6 +39,9 @@
  */


+#ifndef DEBUG
+#define DEBUG 1
+#endif

 #ifndef SDK_CONFIG_H
 #define SDK_CONFIG_H
@@ -7432,7 +7435,7 @@
 // <e> NRF_LOG_BACKEND_RTT_ENABLED - nrf_log_backend_rtt - Log RTT backend
 //==========================================================
 #ifndef NRF_LOG_BACKEND_RTT_ENABLED
-#define NRF_LOG_BACKEND_RTT_ENABLED 0
+#define NRF_LOG_BACKEND_RTT_ENABLED 1
 #endif
 // <o> NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE - Size of buffer for partially processed strings.
 // <i> Size of the buffer is a trade-off between RAM usage and processing.
@@ -7465,7 +7468,7 @@
 // <e> NRF_LOG_BACKEND_UART_ENABLED - nrf_log_backend_uart - Log UART backend
 //==========================================================
 #ifndef NRF_LOG_BACKEND_UART_ENABLED
-#define NRF_LOG_BACKEND_UART_ENABLED 1
+#define NRF_LOG_BACKEND_UART_ENABLED 0
 #endif
 // <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin
 #ifndef NRF_LOG_BACKEND_UART_TX_PIN
@@ -7582,7 +7585,7 @@
 // <4=> Debug

 #ifndef NRF_LOG_DEFAULT_LEVEL
-#define NRF_LOG_DEFAULT_LEVEL 3
+#define NRF_LOG_DEFAULT_LEVEL 4
 #endif

 // <q> NRF_LOG_DEFERRED  - Enable deffered logger.
@@ -7632,7 +7635,7 @@
 // <e> NRF_LOG_USES_COLORS - If enabled then ANSI escape code for colors is prefixed to every string
 //==========================================================
 #ifndef NRF_LOG_USES_COLORS
-#define NRF_LOG_USES_COLORS 0
+#define NRF_LOG_USES_COLORS 1
 #endif
 // <o> NRF_LOG_COLOR_DEFAULT  - ANSI escape code prefix.

@@ -11069,12 +11072,12 @@

 // <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size.
 #ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
-#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23
+#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
 #endif

 // <o> NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE - Attribute Table size in bytes. The size must be a multiple of 4.
 #ifndef NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE
-#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1408
+#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 2000
 #endif

 // <o> NRF_SDH_BLE_VS_UUID_COUNT - The number of vendor-specific UUIDs.

I also modified "nrf_sdh_freertos.c" :

#define NRF_BLE_FREERTOS_SDH_TASK_STACK 256 to 512

(not sur it is useful ?)

I also have seen normal ble_app_hrs is with 247 MTU and 251 GAP data lenth, and it works !

Regards,

Parents
  • 0

    This one took time for me since I had to use SystemView to understand the flow of the data.

    I also enabled stack overflow triggers by enabling 

    #define configCHECK_FOR_STACK_OVERFLOW                                            2

    and adding to main.c

    I can see that there is stack overflow happening in Tmr thread.

    It was actually Timer which needed to have more stack space when ou increase the MTU size. At certain point, the context data within the Tmr thread is increasing in size with increased MTU size. I do not still have the full picture as to why this is happening, but in your case you can increase the timer thread stack space to about 400 bytes and then you won't see this

    #define configTIMER_TASK_STACK_DEPTH                                              ( 400 )

Reply
  • 0

    This one took time for me since I had to use SystemView to understand the flow of the data.

    I also enabled stack overflow triggers by enabling 

    #define configCHECK_FOR_STACK_OVERFLOW                                            2

    and adding to main.c

    I can see that there is stack overflow happening in Tmr thread.

    It was actually Timer which needed to have more stack space when ou increase the MTU size. At certain point, the context data within the Tmr thread is increasing in size with increased MTU size. I do not still have the full picture as to why this is happening, but in your case you can increase the timer thread stack space to about 400 bytes and then you won't see this

    #define configTIMER_TASK_STACK_DEPTH                                              ( 400 )

Children
  • 0 in reply to Susheel Nuguru

    Thanks !

    It works increasing configTIMER_TASK_STACK_DEPTH to just 120
    But I do not understand neither ...

    It is the only thing to modify with MTU, on the SDK example !

  • 0 in reply to Susheel Nuguru

    Any updates on this? What is the root cause of the hardfault that happens when increasing the MTU size?

    I just ran into this same issue myself. I am using the FreeRTOS HRS example as basis for my project. I increased the MAX MTU setting in sdk_config.h from 23 to 512 (maximum allowed). Then I get the hard fault immediately startup (before any connections are made). The debug print in RTT is:

    <00> info> app: Fast advertising.
<00> error> hardfault: HARD FAULT at 0x20006A0A
<00> error> hardfault:   R0:  0x200069C8  R1:  0x20006904  R2:  0x00000004  R3:  0x20006A0A
<00> error> hardfault:   R12: 0x20008050  LR:  0x0002C577  PSR: 0x80000000
<00> error> hardfault: Cause: The processor has attempted to execute an instruction that makes illegal use of the EPSR.

    I tried to get around the issue by increasing the timer thread stack size from default 80 to 800 but it does not help at all.

    EDIT: by using MTU size 247 (instead of the 512 that was my first edit) the hard fault goes away. It is enough to allow me to continue working on my project, but I think it seems kind of weird that changing MTU max value causes a stack overflow. I would need to understand what is happening under the hood so that I can set the stack sizes corretly (not based on guessing or trial/error but on some facts)

  • 0 in reply to TylerD

    It do not seems to be the same error ... for me it was only with ble connection, not before.
    The error was not the same, yours is "illegal use of the EPSR."
    I do not know what it means, just if it can help, I have find this thread about EPSR, when rapid searching :

    devzone.nordicsemi.com/.../usage-fault-in-app-scheduler

  • 0 in reply to Salmat

    It's not exactly same error, but I guess the fault is caused by some stack overflow (like in your case) and in such cases the result can be undeterministic. Typically stack overflow causes symptoms that do not make any sense and seem random.

  • 0 in reply to TylerD

    It is right, stack overflow is unpredictable.

    Small other remarks : I thought max MTU was 247. and any way I also think MTU size has small impact without data length modification (DATA_LENGTH).

Related