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

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
  • Hi,

    Which SDK version are you using?

    What example are you using and proxy_stop() the only modification you made?

    Could you provide the program counter (pc), then we would be able to track where in the softdevice the error occurs.

  • 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.

Reply
  • 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.

Children
  • 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