802.15.4 and Softdevice Compilation Problem

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Tue, 05 Mar 2019 18:34:55 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Mon, 04 Mar 2019 21:38:36 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Mon, 04 Mar 2019 16:13:14 GMT

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?

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Tue, 26 Feb 2019 22:50:48 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Mon, 25 Feb 2019 21:26:53 GMT

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

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Mon, 25 Feb 2019 16:29:21 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Jørgen Holmefjord — Mon, 25 Feb 2019 08:37:22 GMT

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

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

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Sat, 23 Feb 2019 23:03:55 GMT

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?devzone.nordicsemi.com/.../debug.html

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Fri, 22 Feb 2019 00:08:27 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Thu, 21 Feb 2019 21:09:03 GMT

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?

RE: 802.15.4 and Softdevice Compilation Problem

Jørgen Holmefjord — Thu, 21 Feb 2019 14:24:24 GMT

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

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Thu, 21 Feb 2019 13:08:17 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Wed, 20 Feb 2019 22:33:16 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Sat, 16 Feb 2019 20:12:50 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Fri, 15 Feb 2019 16:11:22 GMT

Putting the defines into the Makefile solved the compilation problem, that part is closed. I'm still unable to get the multiprotocol aspect working, After some further experiments, I will post the code.

RE: 802.15.4 and Softdevice Compilation Problem

Jørgen Holmefjord — Fri, 15 Feb 2019 15:46:35 GMT

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.

RE: 802.15.4 and Softdevice Compilation Problem

Ted Herman — Fri, 15 Feb 2019 10:44:17 GMT

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

RE: 802.15.4 and Softdevice Compilation Problem

Jørgen Holmefjord — Fri, 15 Feb 2019 09:58:04 GMT

Hi,

Which project have you included the source files into, and what sdk_config.h file are you using? Are you sure that this sdk_config.h file is included in nrf_raal_softdevice.c/nrf_802154.c, to make the defines visible to the file?

NRF_802154_INTERNAL_RADIO_IRQ_HANDLING should be set automatically if RAAL_SOFTDEVICE is defined. The defines should be provided for the build through the -D compiler option.

Best regards,
Jørgen