SOFTDEVICE: INVALID MEMORY ACCESS at INFO=2

[KelvinCGCG]

Hi,

I'm using the nRF52840 SDKs (15.0.0) and nRF-IEEE-802.15.4-radio-driver(1.1.0). BLE and the CoAP baseed on 802.15.4 work fine, but when I  call this function 

void

ble_advertising_stop_nrf52840(void)

{

  uint32_t err_code = 0;

  PRINTF("ble_advertising_stop_nrf52840() >>>\n");

  err_code = sd_ble_gap_adv_stop(m_adv_handle);

  PRINTF("sd_ble_gap_adv_stop() returned %ld\n", err_code);

  if((err_code == NRF_SUCCESS) ||

     (err_code == NRF_ERROR_INVALID_STATE))

  {

    /* Documentation states that if NRF_ERROR_INVALID_STATE is

    * returned then the ble stack is likely not in an advertising

    * state. So we assume that adverts are off and everything is

    * working as expected. */

    m_is_advertising = false;

  }

  else

  {

    /* reboot device because of fatal error */

    BLE_ERROR_CHECK(err_code);

  }

  PRINTF("ble_advertising_stop_nrf52840() <<<\n");

}    (I checked the err_code above, it is NRF_SUCCESS)

 

After several minutes I got the "SOFTDEVICE: INVALID MEMORY ACCESS" fault. 

According to the INFO = 2 message. There seems to be the radio peripheral violation. After I dumped assembly form   .elf   file. The pc address 0x76ad6 points to a branch in nrf_802154_core.c file. 

The .c file is as below.

Then I added a print(); function before result = false;  then I can't see any messages. Then I print the 

nrf_802154_rsch_timeslot_us_left_get() , it indeed >MAX_CRIT_SECT_TIME.

After I added the print(); funciton, The PC changed ,but it still stoped at nRF-IEEE-802.15.4-radio-driver. If I comment out the ble_advertising_stop_nrf52840(void) function, it works fine.

So can you please help me?

Best regards

[Edvin]

Hello,

So you are using the 802154 radio driver that is used in the SDK for Thread and Zigbee? 

After several minutes I got the "SOFTDEVICE: INVALID MEMORY ACCESS" fault. 

Does this mean that you are calling sd_ble_gap_adv_stop() several times over several minutes, or does it take several minutes for the error to occur after calling it once?

What else are you doing in the meantime? I assume you are not advertising? Are you in a connection? Are you scanning? Do you overstay any of the timeslots? I didn't understand what you meant by:

nrf_802154_rsch_timeslot_us_left_get() , it indeed >MAX_CRIT_SECT_TIME.

Does the issue occur inside a timeslot, or outside?

After I added the print(); funciton, The PC changed ,but it still stoped at nRF-IEEE-802.15.4-radio-driver.

That is probably because of the rebuild that things get shuffled around. 

Is there anything else I should know? Are you using FreeRTOS?

Best regards,

Edvin

[KelvinCGCG]

Hi Edvin,

Thank you for your reply.  The 802154 radio driver is an individual version, I uploaded the radio driver for your reference.

nRF-IEEE-802.15.4-radio-driver.zip

Does this mean that you are calling sd_ble_gap_adv_stop() several times over several minutes, or does it take several minutes for the error to occur after calling it once?

I called this function only once. It takes several minutes for the error to occur.

What else are you doing in the meantime?I assume you are not advertising? Are you in a connection? Are you scanning? 

 After sd_ble_gap_adv_stop() is called, I use nRFconnect mobile app to see RSSI Graph.It confirms it's not advertising. I am not in a connection. And I'm not scanning. 

 I didn't understand what you meant by:nrf_802154_rsch_timeslot_us_left_get() , it indeed >MAX_CRIT_SECT_TIME.

since the PC stopped here.

I checked the remaining_timeslot_time_is_enough_for_crit_sect()

 it indeed >MAX_CRIT_SECT_TIME.

I mean nrf_802154_rsch_timeslot_us_left_get() >= MAX_CRIT_SECT_TIME;

below are nrf_802154_rsch_timeslot_us_left_get()  values after Stopped BLE Adverts.

Do you overstay any of the timeslots?

I don't know how to estimate this.But  If I comment out the ble_advertising_stop_nrf52840(void) function, it works fine. So I don't think I overstay any of the timeslots.

Does the issue occur inside a timeslot, or outside?

Sorry, I don't know how to estimate this either. I can't debug the code.I can only print messages.

Is there anything else I should know? Are you using FreeRTOS?

I am using CONTIKI.

[Edvin]

KelvinCGCG said:

I mean nrf_802154_rsch_timeslot_us_left_get() >= MAX_CRIT_SECT_TIME;

So this means that when you do this measurement, you still have enough time. Adding an RTOS complicates things a bit. It adds delays that you may or may not have control over. I am not at all familiar with CONTIKI, but could the case be that you measure the nrf_802154_rsch_timeslot_us_left_get(), there is still enough time in the timeslot, and then you start to perform your task. But if you are interrupted by something in the OS, and the remaining time runs out before you finish your task, and you don't have time to leave the timeslot before it runs out, then this will cause the kind of assert that you are seeing.

I don't know what your project looks like. Where do you exit your critical timeslot? If you add a log there as well, you should see that they will enter and exit every other time. Is the last thing that happens before the issue that it enters or exits a critical section?

I don't know whether it is relevant or not, but have you tried upgrading to SDK17.1.0 to see if that helps? I do remember seeing some bugs in the timeslots when using 802154, but I don't remember if that was using this driver, or something else.

Best regards,

Edvin