802.15.4 and Softdevice Compilation Problem

[Ted Herman]

Hello,

I am trying to use Softdevice and the latest Github version of 802.15.4 support. The make (using linux/armgcc) fails on 

nrf_raal_softdevice.c

because nrf_802154_radio_irq_handler is undefined (implicitly defined) and/or missing. I had thought that by putting some defines into the sdk_config.h that it would be taken care of, so I put these into the sdk_config.h for the make:

// github.com/.../Source-files-and-defines
//
#ifndef RAAL_SINGLE_PHY
#define RAAL_SINGLE_PHY 0
#endif

#ifndef RAAL_SIMULATOR
#define RAAL_SIMULATOR 0
#endif

#ifndef RAAL_SOFTDEVICE
#define RAAL_SOFTDEVICE 1
#endif

#ifndef ENABLE_DEBUG_LOG
#define ENABLE_DEBUG_LOG 0
#endif

#ifndef ENABLE_DEBUG_ASSERT
#define ENABLE_DEBUG_ASSERT 0
#endif

#ifndef ENABLE_DEBUG_GPIO
#define ENABLE_DEBUG_GPIO 0
#endif

#ifndef ENABLE_FEM
#define ENABLE_FEM 0
#endif

#ifndef NRF_802154_INTERNAL_RADIO_IRQ_HANDLING
#define NRF_802154_INTERNAL_RADIO_IRQ_HANDLING 0
#endif

(the last define was needed elsewhere, to get nrf_802154.c to have  nrf_802154_radio_irq_handler in its code).

I might also mention that the names of core components in the page https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver/wiki/Source-files-and-defines seems not to agree with a more recent version of the 802.15.4 code.

Ted Herman

[Ted Herman]

Further investigation and some code changes show the following behavior. 

First, after initializing BLE, advertising, etc (using the ble_app_hrs program), the code calls nrf_802154_init(), then channel_set, then receive(). 

In each cycle of the main loop, after idle_state_handle() is invoked, there is a call nrf_delay_ms(1000), followed by an attempt to xmit an 802.15.4 packet. Before the xmit attempt, there is now a call to get and log the result of nrf_802154_get_state. The log shows that the state is initially STATE_RECEIVE, as it should be. However, all subsequent attempts find that the state is STATE_TRANSMIT, implying that the 802154 stack never exits the transmit state. This could be because RAAL blocks, or because the Makefile/sdk_config use incorrect timers, who knows really. 

Any idea how to proceed on this? I'd quite like to get multiprotocol of BLE/802.15.4 working, and I haven't even got as far as trying to receive 802.15.4 packets in a multiprotocol context.

[Ted Herman]

I have been looking at examples/multiprotocol/ble_thread/ble_thread_swi_template to learn from another example of multiprotocol. I see there how BLE is disabled in order to switch to Thread,

static void switch_ble_to_thread(void)
{
    ASSERT(m_connection_state == CONNECTION_STATE_BLE_DISABLE);

    ble_stack_deinit();
    thread_instance_init();
}

My question is this: in order to get 802.15.4 to function properly, should BLE be disabled first? The impression I got from https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver/wiki/Multiprotocol-support which shows the interleaving of BLE and 802.15.4, although that is for the Thread case. I would need to use raw transmit, so using Thread or Zigbee seems inappropriate. Other comments from your earlier answer https://devzone.nordicsemi.com/f/nordic-q-a/36814/nrf52840-multiprotocol-ble-802-15-4-without-zboss/141729#141729 motivated using the Nordic github repo for 802.15.4. 

[Jørgen Holmefjord]

I'm not sure which state you expect the application to be in. You put it in receive state in motesetup() function, but I cannot see anywhere else in your code that you change the state of the radio from transmit after first call to motetx().

You are looking at a switched multiprotocol application, the 802.15.4 driver also support dynamic multiprotocol solution, where you can run softdevice and 802.15.4 "at the same time".

[Ted Herman]

OK, so don't use the switched multiprotocol application. However, even if the 802.14.4 driver remains in STATE_TRANSMIT, one would expect to see an actual transmission on the radio - which is not observed. Earlier documentation about the SDK would lead me to think that using the timeslot API would be appropriate, however I see that the code in nrf_raal_softdevice.c does use the timeslot API. Would you suggest that, in addition to having nrf_raal_softdevice.c in the make, that the app also request a radio timeslot and wait for the callback before initiating the nrf_802154_transmit_raw call? Otherwise, it seems like there is a conflict. Or does transmit_raw internally call raal to get the timeslot?

[Ted Herman]

Looks like using rsch might be the solution. http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v2.0.0%2Fgroup__nrf__rsch.html - will test this soon.