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]

In another experiment, tried backing off from most recent github version of the nRF-IEEE-802.15.4-radio-driver and instead using the version tree/68a54db (v1.2.1) because the release_notes.txt say this was verified in the Thread stack libraries. However, the results are the same, transmit does not occur when trying multiprotocol of BLE + 802.15.4 (without Zigbee or Thread).

[Ted Herman]

Reading more through the code and documentation, it appears that the 802.15.4 with softdevice uses RTC2 in one of the timers. I made sure that RTC and RTC2 are enabled in the sdk_config.h, but that seems to have no effect. I noticed that nrf_802154.c calls request_transmit, but always with the immed parameter as false, and the code in nrf_802154_core.c then forces the state to be RADIO_STATE_TX, which is seen in the debug log. I'm not sure how to track this further, why subsequent events (and there are events such as extending the timeslots) do not trigger the calling of the packet transmit operation.

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