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]

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.

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