• State Not Answered
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 1190 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 280999
Options

MPSL ASSERT: 105, 75 when initiating 802.15.4 repeatedly, tips for using 802.15.4 in timeslots?

devtester

Hello Devzone,

  1. I am trying to run timeslotted 802.15.4 alongside BLE using NCS. I have started from this example, replacing the propiertary RF calls with calls to 802.15.4 and manages to set up timeslots in between the BLE connection events. From within the timeslots, is it safe to call nrf_802154_ functions, or do I have to use the RADIO HAL for this? Is the proper way of having 802.15.4 communication to use nrf_802154_init() at the start of the timeslot, transfer data and then call nrf_802154_deinit() when the TIMER0 triggers, right before the timeslot ends?

  2. If I call nrf_802154_init() and nrf_802154_deinit() after each other repeatedly, it throws an MPSL assert on the n:th init() after a fixed number of cycles. Why is that, and is there something I can do to prevent it? This occurs even if I create an empty project without BLE or timeslotting mechanism. It also always asserts after the same number of cycles for the same configuration, but varying through configs.
    This is the error output from the empty project, calling nrf_802154_init() and nrf_802154_deinit() repeatedly:

    00> *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
00> 
00> Initing
00> Deiniting
00> Initing
00> Deiniting
00> Initing
00> Deiniting
00> Initing
00> Deiniting
00> Initing
00> E: MPSL ASSERT: 105, 75
00> E: r0/a1:  0x00000003  r1/a2:  0x20003eb0  r2/a3:  0x20003eb0
00> E: r3/a4:  0x00000001 r12/ip:  0x00000000 r14*** Booting Zephyr OS build v2.6.0-rc1-ncs1

    This is my main for reproducing this issue: 
    #include <zephyr.h>
#include <device.h>
#include <sys/printk.h>
#include <sys/byteorder.h>

void main(void)
{
	int blink_status = 0;
	int err;
	printk("\n");

	while (1) {
		++blink_status;
		k_sleep(K_MSEC(500));

		if (blink_status % 2){
			printk("Initing\n");
			nrf_802154_init();
		}
		else{
			printk("Deiniting\n");
			nrf_802154_deinit();
		}
	}
}

    If I call it from the timeslots, it asserts already on the 3rd init, with this error code: 

    00> timeslot_start(len_us: 25000)
00> 802.15.4 Initing
00>  802.15.4 deiniting
00> 802.15.4 Initing
00>  802.15.4 deiniting
00> 802.15.4 Initing
00> E: MPSL ASSERT: 105, 75
00> E: r0/a1:  0x00000003  r1/a2:  0x20010b50  r2/a3:  0x00000001
00> E: r3/a4:  0x20010bc5 r12/ip:  0x00000000 r14/lr:  0x00027217
00> E:  xpsr:  0x61000000
00> E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
00> E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
00> E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
00> E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
00> E: fpscr:  0x0003aefd
00> E: Faulting instruction address (r15/pc): 0x00027222
00> E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
00> E: Current thread: 0x200020b8 (timeslot_thread)
00> E: Halting system

     (Using timeslots, I also does some more stuff in the init such as setting addresses and channel)

Hope someone can help me with this!
I use NCS 1.6.1 and the nRF52840DK.

Parents Reply
  • 0 in reply to Marjeris Romero

    Hi Marjeris,

    I have already looked into that sample quite in depth and tried to modify it to my needs. It does not use the timeslot for any radio communication whatsoever though, therefore my first question. It also doesn't take considerations to already scheduled BLE slots, that is why I switched to the the example I linked.

    As I said in the part you cited, I already can allocate my timeslots without issues, that's not the problem. The problem is how to use 802.15.4 within them and why calling nrf_802154_init() repeatedly asserts.

Children
  • 0 in reply to devtester

    Hi,

    I have asked our developers and mutiprotocol between 802.15.4 and BLE is done in a seamless manner in our SDK, so there should be no need for to call nrf_802154_init() and nrf_802154_deinit() by yourself, as this is suppose to be done "under the hood" by the stack. Here for example there is an overlay to add BLE multiprotocol to a Zigbee example if you want to try running an example with multiprotocol: https://github.com/nrfconnect/sdk-nrf/blob/main/samples/zigbee/light_switch/overlay-multiprotocol_ble.conf

  • 0 in reply to Marjeris Romero

    Hi again,

    Thanks, that explains quite much and is of course more analogue with how it works without the timeslot mechanism.

    One follow up question, do I have to manually put the nRF_802154 module into sleep mode? If I don't do this, it seem like it blocks all new timeslot requests. Does that mean I have to temporarily cancel 802.15.4 rx if I need to extend the timeslot?

    The overlay sample you linked does not seem to be of too much use unfortunaley, since it doesn't manually call the timeslot functions but rely on it running in the background (which is does very well). Since I want to synchronize my 802.15.4 transmission with the BLE connection events, I have to manually interact with the timeslots as far as I've understood.

  • 0 in reply to devtester

    Related to that, if I do a dummy timeslot program, requesting one timeslot and sending one 802.15.4 frame form it, the callbacks does not seem to be executed until after the timeslot ends.

    Here's a screenshot of two runs where I send a frame in the beginning of my timeslot. The source code are identical except for the timeslot length that is doubled in the second image:



    Is this behaviour expected? How can I have a transmission using 802.15.4 inside my timeslot if the callbacks aren't executed until it ends?

Related