• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 233 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288720
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

proxy_stop() causes NRF_FAULT_ID_SD_ASSERT after ~30 Min

user79368

I'm trying to disable proxy visibility of mesh node after its been provisioned by calling (from APP timer's context) proxy_stop() function. Though i'm getting NRF_FAULT_ID_SD_ASSERT fault withing 30 min to 1 Hr after call.

I have another node which is running for couple of days that does not call proxy_stop() on power up. So its definately proxy_stop() call is making it happen.

I have also tried caling adv_start(PROXY_ADV_TYPE_NETWORK_ID, true); with mesh_adv_params_set() supplied with 10s interval time, it still fails on SD assert.

Addition: BTW if I were to disable proxy uisng mobile provisioner(nRF Mesh) it still fails on SD assert !

Can anyone share any thoughts ?

Softdevice i'm using is *_s132_7.2.0.hex

Parents Reply Children
  • 0 in reply to user15475

    Hi,

     SDKs are nRF5_SDK_17.0.2 & nrf5_SDK_for_Mesh_v5.0.0

    I have adopted dimming_server from mesh SDK. Modifications to dimming server made are as below

    Only generic level server is kept other models removed and Vendor model added.

    Flash Data Storage (FDS) is enabled for app's data storage.

    I have 2 app timers running, one app timer runs every 2ms while serving vendor model requests and then its stopped.Another app timer runs every 1 sec this too is not permanently on. In this 1 sec app timer i'm calling proxy_stop() after 45 min (for testing after 30 sec).

    I also have UART/SPI/PPI going on while handeling vendor model application. All peripheral handled using nrf_drv_* driver.

    app_error_fault_handler() NRF_FAULT_ID_SD_ASSERT assert gets called anything between 10 min to 1 Hr after calling proxy_stop().

    pc 0x00015810, info 0x00000000, id 0x00000001     @app_error_fault_handler()

    What i'm wondering at is why variable time(few min to an hour) for an assert ? Does RC oscillator for RTC clock has anything to do with it?

  • 0 in reply to user15475

    Hi,

    Pm7 said:
    Flash Data Storage (FDS) is enabled for app's data storage.

    Any specific reason you want to use FDS instead of Flash Manager?

    Seems like you have a lot going on in your application, it is hard to know exactly what is causing this issue. 

    It seems like the assert at 0x15810 is because the SoftDevice got an unexpected radio interrupt, this is typically due to the application used the radio outside of the timeslot. I suggest try to increase TIMESLOT_END_SAFETY_MARGIN_US in steps of 100us up to 1000us.

    This thread have a discussion on this topic, might be of help.

  • +1 in reply to user15475

    Hi,

    While I was trying to discard new draft reply, I ended up deleting my last reply to this conversation.

    It seems value of NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 16 was a part issue, after settng it to 2 one board lasted so for 3 days.

    Though another board could not survive with lowering of _TEMP_CTIV value. To fix that increasing TIMESLOT_END_SAFETY_MARGIN_US to 500(from 100) has helped.

Related
Terms of service