• State Not Answered
  • Replies 6 replies
  • Subscribers 74 subscribers
  • Views 2425 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 214901
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Receiving an NRF_FAULT_ID_SD_ASSERT error some non-deterministic time after connecting via BLE

JulianMA

I am constantly receiving an NRF_FAULT_ID_SD_ASSERT error within a non-deterministic time after connecting via BLE.

The program Counter is always 75936 and Info == 0. I am using the SDK 14.2 and the softdevice 5.0 (which is not perfectly in line with the compatibility matrix, although I downloaded this configuration in January 2018 "as it is" from your site...).

I enclosed the sdk_config.h, because this was often the the cause of problems in the past.

I would be glad if you could provide me some hints where to look at; hopefully I am able to do the rest.

Thank you in advance, JulianMA.

sdk_config.h

Parents
  • 0

    Hi MartinBL,

    many thanks for your fast reply! I think that you provided lots of help already: I got the message that this problem is likely to be related to "timing" issues.

    @ About my application / hardware:

    My application is currently run on custom PCB which follows Nordic's design guides as close as possible. It is in an absolute development state. I have three slightly different layouts which are behaving identical with respect to the "assert".

    @ Purpose of my hardware:

    The application is intended to read values from a sensor for ultraviolet radiation via TWI and to notify the sensor readings via BLE (peripheral to central). I adopted your heartrate-peripheral application (ble_app_hrs) and modified it to meet my requirements (add new characteristics, etc.).

    @ What is the application doing during failure:

    The application is in the "connected" state. That is all I can say; I assume that the ASSERT is triggered by a lower-level system interrupt.

    @ Problems with TWI:

    --> can be excluded, since I commented all TWI issues out and the problem persists.

    @ Are you using a lot of interrupts in your application?

    No.

    @ Are you using the time slot API?

    No.

    @ Is this happening on more than on device? If so what is the failure rate?

    It happens on all my three custom devices. All of them are slightly different but as close as possible to the Nordic design guides.

    @ Are you doing flash operations in your application?

    Only in the peer manager (e. g. for bonding). This should only be done during pairing and should therefore not be the reason for the assert.

    @ Are you at any point disabling interrupts to execute time critical code? (some drivers and libraries in the SDK do this under the hood)

    Hmmm. I do not disable interrupts by myself; however if this is done under the hood of SDK libraries, I cannot exclude this.

    @ As a result I see the following tasks as my "homework":

    1. I will test another hardware (e. g. the "Sparkfun Breakout Board")

    2. I will cut down the application in order to reduce the number of timers and anthing that has to do with "time"

    3. I will modify the available clock sources in the sdk_config.h.

    4. If I manage to identify a solution I will notify you.

Reply
  • 0

    Hi MartinBL,

    many thanks for your fast reply! I think that you provided lots of help already: I got the message that this problem is likely to be related to "timing" issues.

    @ About my application / hardware:

    My application is currently run on custom PCB which follows Nordic's design guides as close as possible. It is in an absolute development state. I have three slightly different layouts which are behaving identical with respect to the "assert".

    @ Purpose of my hardware:

    The application is intended to read values from a sensor for ultraviolet radiation via TWI and to notify the sensor readings via BLE (peripheral to central). I adopted your heartrate-peripheral application (ble_app_hrs) and modified it to meet my requirements (add new characteristics, etc.).

    @ What is the application doing during failure:

    The application is in the "connected" state. That is all I can say; I assume that the ASSERT is triggered by a lower-level system interrupt.

    @ Problems with TWI:

    --> can be excluded, since I commented all TWI issues out and the problem persists.

    @ Are you using a lot of interrupts in your application?

    No.

    @ Are you using the time slot API?

    No.

    @ Is this happening on more than on device? If so what is the failure rate?

    It happens on all my three custom devices. All of them are slightly different but as close as possible to the Nordic design guides.

    @ Are you doing flash operations in your application?

    Only in the peer manager (e. g. for bonding). This should only be done during pairing and should therefore not be the reason for the assert.

    @ Are you at any point disabling interrupts to execute time critical code? (some drivers and libraries in the SDK do this under the hood)

    Hmmm. I do not disable interrupts by myself; however if this is done under the hood of SDK libraries, I cannot exclude this.

    @ As a result I see the following tasks as my "homework":

    1. I will test another hardware (e. g. the "Sparkfun Breakout Board")

    2. I will cut down the application in order to reduce the number of timers and anthing that has to do with "time"

    3. I will modify the available clock sources in the sdk_config.h.

    4. If I manage to identify a solution I will notify you.

Children
Related
Terms of service