• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 1296 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 204082
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

hardfault on an sd_ble_gatts_hvx call in sdk 14.2.0

Sensorion

Referencing  another trouble ticket

https://devzone.nordicsemi.com/f/nordic-q-a/22621/hardfault-on-an-sd_ble_gatts_hvx-call-in-sdk12-3

I am experiencing the same issue as listed in the reference issue.  Using SDK 14.2.0, FreeRTOS project built off of FreeRTOS example. 

Battery service can send notifications just fine, but my custom service cannot. I am using the FreeRTOS xTimer to send out a 20 byte packet on a periodic base. Call to this function fails on first call.  I have seen other that have had the same issue, or similar, and perhaps it is a priorities issue but I cannot fix this.

Cheers

Parents
  • 0

    Hi Sensorian,

    If it is exactly the SVC call you mentioned that causes the hardfault  , then it most likely looks like the issue with priority settings in your project or calling SVC at at the wrong place 

    As you can see that for nRF52 devices using our BLE softdevice, the SVC priority is set to 4. If you are calling any sd_xxx functions from a context that has interrupt priority set to 4 or lower in number (3,2 1 or 0) then the call would hardfault. 

    Also FreeRTOS uses BASEPRI/PRIMASK (nrf52/nrf51) register to mask interrupts to execute code in critical section. You cannot call any softdevice API in this critical region of code.

    I would see no other issue as many customers are using FreeRTOS to implelment their custom services without any issues.

    BTW, new SDK release SDk15 have upgraded FreeRTOS kernel from 8.0.0 to 10.0.0, may be you would like to use it (not to solve this problem, but to get benefited from the newer RTOS version)

Reply
  • 0

    Hi Sensorian,

    If it is exactly the SVC call you mentioned that causes the hardfault  , then it most likely looks like the issue with priority settings in your project or calling SVC at at the wrong place 

    As you can see that for nRF52 devices using our BLE softdevice, the SVC priority is set to 4. If you are calling any sd_xxx functions from a context that has interrupt priority set to 4 or lower in number (3,2 1 or 0) then the call would hardfault. 

    Also FreeRTOS uses BASEPRI/PRIMASK (nrf52/nrf51) register to mask interrupts to execute code in critical section. You cannot call any softdevice API in this critical region of code.

    I would see no other issue as many customers are using FreeRTOS to implelment their custom services without any issues.

    BTW, new SDK release SDk15 have upgraded FreeRTOS kernel from 8.0.0 to 10.0.0, may be you would like to use it (not to solve this problem, but to get benefited from the newer RTOS version)

Children
No Data
Related
Terms of service