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]

Hello,

Here is what I am trying. I copied ble_hrs from the ble_peripherals as the base for the experiment. Then I added statements to initialize 802.15.4 and set the channel (based on another program which successfully used raw transmit of 802.15.4 frames) -- these statements come just after setting up BLE, advertising, etc. Then, in the idle loop, I added a call to a procedures that (raw) transmits a packet. Finally, attempting to get this to compile, the Makefile needed all the core components mentioned in the 802.15.4 wiki, although some of these no longer exist, so I had to improvise by searching the current (cloned a week ago) git repo to attempt a compile. Of course the sdk_config.h needed the extra defines, also mentioned in the wiki. It was unclear whether all of these should be defined 1 or 0, so I defined them to be 1. 

The result of doing all of this is that no matter which way I tried, there was some missing reference to IRQ handling, hence my attempt after studying the code to add that extra define - not mentioned in the wiki.

Going further, I made a new copy of the entire Nordic SDK and forced manually everything to be defined, so it would compile and I could flash it onto an nRF52840. The result, looking at the UART log, was the the very first 802.15.4 transmit raw gets a result of 1 (tx busy), but all subsequent transmits get 0. None of them actually work. I tried digging deeper with debug mode, but I was unable to get JLink and GDB server missing because of a missing so-lib in Linux, even though that very library is present.

Sorry if the above is not specific or accurate in all details. Due to the time difference between us, I do not have access to the equipment and code for some hours. I would appreciate suggestions on how to proceed from here. 

Thank you,

Ted

[Jørgen Holmefjord]

The sdk_config.h file is not included in the 802.15.4 driver source files, you have to set the defines directly as symbols in the makefile for it to be visible to all files in the project. If you could upload your project, that would really help with being able to debug this issue and see what is happening in your application.

[Ted Herman]

It is unclear how to upload a project onto devzone, so I put an example of the application on a github repo: https://github.com/TedHerman/blehrs802154 

You can clone this and find the code, the sdk_config.h, and the Makefile. 

On about line 8 of the Makefile there is an explanation of version dependencies (which SDK, which 802.15.4 driver, etc). 

This compiles cleanly, but does not succeed in transmitting 802.15.4 packets, although a non-BLE version of the same code does transmit.

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