Larger MTU results in HardFault

RE: Larger MTU results in HardFault

Corey — Wed, 17 Jun 2020 15:24:38 GMT

it'ｓworks after according your suggest.

Increasing configTIMER_TASK_STACK_DEPTH to 512

RE: Larger MTU results in HardFault

Susheel Nuguru — Fri, 04 Oct 2019 05:39:50 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: Larger MTU results in HardFault

Susheel Nuguru — Mon, 26 Nov 2018 14:34:57 GMT

i am wondering why I am not able to reproduce this. what is peer you are testing this with? I am guessing probably there are some old values in my FreeRTOSConfig.h file. Have you tried increasing the default configTOTAL_HEAP_SIZE in there? I normally use (4092 * 2) as default. But if you are limited by RAM, then try to increase it to (4092 + 2048).. I cannot think of anything else.

RE: Larger MTU results in HardFault

Dave_couling — Fri, 23 Nov 2018 19:27:08 GMT

I could not resolve this. Unfortunately I had to limit our MTU and DL settings for our product release.

RE: Larger MTU results in HardFault

Susheel Nuguru — Fri, 23 Nov 2018 09:17:41 GMT

sorry Dave, this thread skipped my queue, I did not see that you replied. Do you still have this problem ? I am confident that due to my delay in answer, you must have dug into it yourself. If you found the solution, can you please update us.

RE: Larger MTU results in HardFault

Dave_couling — Thu, 15 Nov 2018 00:27:58 GMT

I just took the freeRTOS example and increased the MTU to 247 and DL to 251. Works fine until you connect. It crashes during connection

RE: Larger MTU results in HardFault

Susheel Nuguru — Wed, 14 Nov 2018 08:04:06 GMT

I could not reproduce it . Can you help me to reproduce this error Dave?

RE: Larger MTU results in HardFault

Dave_couling — Tue, 06 Nov 2018 04:08:01 GMT

This is exactly the error I'm seeing. Have you solved this Jeff? Any comment from Nordic? Susheel Nuguru ?

RE: Larger MTU results in HardFault

Jeff Breaking — Fri, 26 Oct 2018 20:00:27 GMT

Here are my source files for reference. Based on the ble_apphrs_freertos. The only change I really made was trying to add MTU and DL

devzone.nordicsemi.com/.../12032.main.c devzone.nordicsemi.com/.../2577.FreeRTOSConfig.h

devzone.nordicsemi.com/.../40146.sdk_5F00_config.h

RE: Larger MTU results in HardFault

Jeff Breaking — Fri, 26 Oct 2018 19:24:41 GMT

For me everything works up to GAP DL 174 and MTU 170. Beyond this causes hardfaults on connection

RE: Larger MTU results in HardFault

Jeff Breaking — Fri, 26 Oct 2018 19:11:49 GMT

I also see this error with the freeRTOS example. On Connect, the connect event propagates through the system. But quickly the chip goes into Hardfault reaching the Hardfault_c_handler().

Logging shows:

<info> app: HRS FreeRTOS example started.
<debug> nrf_sdh_freertos: Enter softdevice_task.
<info> app: Fast advertising.
<info> app: Slow advertising.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connected
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<info> app: Data Length Event Recevied: 251
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: Data Length Event Recevied: 251
<debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<info> app: Data Length Event Recevied: 251
<error> hardfault: HARD FAULT at 0x0002E140
<error> hardfault: R0: 0x00000040 R1: 0x20008700 R2: 0x74007300 R3: 0x74007300
<error> hardfault: R12: 0xA5A5A5A5 LR: 0x0002C6F1 PSR: 0x2100020E
<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: 0x7400730C

The Hardfault always seems to occur after Connection on a call to taskSELECT_HIGHEST_PRIORITY_TASK(); inside task.c.

My settings are: SDK15.2, MTU 247, GAP DL 251, Len evt enabled, sdk_ble_task_depth 512

It seems like the hardfault occurs shortly after the MTU handshaking after connection. I see service discovery occur just before everything blows up.

RE: Larger MTU results in HardFault

Susheel Nuguru — Thu, 14 Jun 2018 13:08:01 GMT

Thanks Ken,

Please comeback here to update us, it will be really helpful for others.

RE: Larger MTU results in HardFault

Ken — Thu, 14 Jun 2018 11:56:28 GMT

I was able to get it to work, but I could not find any commit clearly indicating what I changed to get it to work properly.

I also started with the ble_app_hrs_freertos, adding a 512 byte characteristic and increased the MTU size to 158.
I'll look a but closer at the GIT history to see if I can either reproduce with sharable code.

RE: Larger MTU results in HardFault

Susheel Nuguru — Thu, 14 Jun 2018 07:54:22 GMT

no error or hardfault for me in the example atleast when i change the MTU size. But since you both are getting the same thing, i cannot overlook it. Can one of you give me your setup?

RE: Larger MTU results in HardFault

Susheel Nuguru — Thu, 14 Jun 2018 07:33:10 GMT

ok , i need to reproduce this. Working on it.

RE: Larger MTU results in HardFault

Dave_couling — Wed, 13 Jun 2018 17:53:22 GMT

ble_app_hrs_freertos and SDK 15

RE: Larger MTU results in HardFault

Susheel Nuguru — Wed, 13 Jun 2018 07:47:29 GMT

which example is it? did you try with the same SDK?

RE: Larger MTU results in HardFault

Dave_couling — Fri, 08 Jun 2018 18:52:46 GMT

I get the same issue when I increase the MTU size. It only hardfaults on a Connection, but advertises fine. Did you end up solving this?

RE: Larger MTU results in HardFault

Susheel Nuguru — Mon, 22 Jan 2018 20:00:12 GMT

with the info you gave, it is hard to say what it is without being able to reproduce it. Have you tried trying to find out which instruction caused hardfault? Try this