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]

By extending the the use of the debug log (a couple more  nrf_802154_log calls), it appears that your suggestion is the case, that there is a problem with the high frequency clock. The precondition for HFCLK is not being satisfied in nrf_802154_rsch.c, so the m_approved_prios array is insufficient for transmit. The Makefile does specify using nrf_802154_clock_sdk.c and does not use nrf_802154_clock_nodrv.c. My question is, how can I debug this HFCLK issue? Is there some simple test that could be put into code to learn more? Could there be some dependencies (in make options, in sdk_config) that should be changed?

[Ted Herman]

One more experiment I tried. After reading  this page (possibly outdated) there appears to be the option of requesting that the high frequency clock be turned on before the transmit attempt. So, I put in a call to nrf_802154_clock_hfclk_start() just after the nrf_802154_init() call. Then, in the application before attempting transmit, the code logs the result from nrf_802154_clock_hfclk_is_running() before the transmit_raw. The result is that the high frequency clock is reported to be running (by softdevice). So, now I am confused, my previous hypothesis looks invalid, because still there is no actual transmit done.

[Ted Herman]

Yet another experiment confirms the problem with the high frequency clock. The problem may be that the callback to nrf_802154_clock_hfclk_ready() does not occur. I describe next how that was confirmed. 

First, in the experimental app, right after the call to nrf_802154_init(), there is a call to start the high frequency clock (nrf_802154_clock_hfclk_start). When the app is running, button 3 schedules an event to do 802.15.4 transmit raw. This scheduled event prints the result of nrf_802154_clock_hfclk_is_running(): it is true.

Second, the code of nrf_802154_rsch is changed to eliminate calls that stop or start the high frequency clock (presuming that hfclk is already running).

Third, in the callback  nrf_raal_timeslot_started(), a new statement is inserted: prec_approved_prio_set(RSCH_PREC_HFCLK, RSCH_PRIO_MAX); that effectively simulates what would have been done in the nrf_802154_hfclk_read() callback. Thus the callback to start a timeslot establishes two prerequisites, the HFCLK running and the RAAL Timeslot started. 

The result, when I run the experiment (for the very first time) is success: there is an 802.15.4 transmit which is received by another nRF52840. Despite the success of this experiment, it remains unknown why this multiprotocol situation happens.

Also: using SDK15.3 and the latest github clone of the Nordic 802.15.4 protocol stack.