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]

I have a trace of some events attempting to transmit the 802.15.4 packet. As you can see from the debug log, timeslots were granted by softdevice and raal, though they were not used by transmit. I see there is a csma_ca failure, is that the reason that the packet is never transmitted? The request was nrf_802154_transmit_raw(buffer,false), which got back true (so the transmit state was confirmed). What other steps should I try for debugging?debug.html

[Jørgen Holmefjord]

I checked this with the developer, here are two tips that could help you with your issue:

1. Customers should use only functions from nrf_802154.h file. All other headers like nrf_802154_rsch.h or RAAL or Timeslot API are internal and should not be used unless you modify the driver itself.
2. According to attached debug log it looks that the 802.15.4 driver get timeslot for transmission. However, it does not start the transmission. It is most likely caused by problem with high frequency clock. Check the `m_approved_prios` array from nrf_802154_rsch.c a few ms after requesting transmission. I expect that the first element in the array is 0 while the second one is non-zero. If this is confirmed, the problem is with 'src/platform/clock/nrf_802154_clock.h' implementation. We provide two example implementations. Within nRF SDK `nrf_802154_clock_sdk.c` can be used.

[Ted Herman]

Checking the content of the m_approved_prios array, an experiment showed that the first two elements are 0 and the third is 4 (where 4 means RSCH_PRIO_TX). Then I looked for problems with the high frequency clock. It is using nrf_802154_clock_sdk.c, which should be the correct choice for s140 multiprotocol. I then noticed that there is a subdirectorynRF-IEEE-802.15.4-radio-driver/external not being used in the Makefile, where there is  external/hal/nrf_clock.h and some other headers (also, there is external/softdevice). Should these be part of the include paths for the make? I tried putting the external/hal in the path, before the usual modules/nrfx/hal, but then the make fails because boards.c does not have the ASSERT macro defined.

Also, I tried a few other things, like trying to use lp_timer_none, but that also does not compile: delayed_trx needs timer_sched, then timer_coord, and then functions only in lp_timer_nodrv. 

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