NRF_802154_USE_RAW_API is always being set to 1

[Richard]

We want to use the non raw functions of 802154 such as "nrf_802154_transmit" however they're compiled out by the definition of NRF_802154_USE_RAW_API being set to 1.

How do we ensure this is set to 0?

Using extra CMake arguments didn't work:  Defining preprocessor options using Visual Studio Code 

I've tried variations of the below in the top level CMakeLists.txt file:

add_definitions(-DNRF_802154_USE_RAW_API=0)

add_compile_options(-DNRF_802154_USE_RAW_API=0)

add_compile_definitions(-DNRF_802154_USE_RAW_API=0)

target_compile_options(-DNRF_802154_USE_RAW_API=0)

and also adding CONFIG_IEEE802154_RAW_MODE=n in the overlay file appears to do nothing.

We're trying to get the server and client echo samples to compile having added this:

    nrf_802154_init();

    uint8_t bb[2];
    nrf_802154_transmit(bb, 2, NULL);

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.2/zephyr/samples/net/sockets/echo_client/README.html#sockets-echo-client-sample

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.2/zephyr/samples/net/sockets/echo_server/README.html#sockets-echo-server-sample

[Edvin]

Hello,

After you set CONFIG_IEEE802154_USE_RAW_API=0 in your configurations and build. Does the build log give any warnings saying something like "tried setting it to n, but got value y." ?

If you can't find it, then you can also search for the file autoconf,h" inside your build folder. You should probably see at least two of them (one for each core). Do you see CONFIG_IEEE802154_RAW_MODE in any of those files? If so, what are their values?

That being said, I am not familiar with those samples, and whether they actually are set up to use the nrf_802154 API, or zephyr's 802154 stack. Is there any particular reason why you need to use 802154 directly? Do you intend to use it with OpenThread or Zigbee?

Best regards,

Edvin

[Richard]

Hello Edvin,

The build log doesn't have anything like that. There are two autoconf.h files as you say, there are the sub directories if that helps:
build\zephyr\include\generated
build\multiprotocol_rpmsg\zephyr\include\generated

However, CONFIG_IEEE802154_RAW_MODE isn't shown in either file.

For legacy reasons we have to use 'simple' 802.15.4. We were forced to write our own stack to use multiprotocol on the nrf52840 as detailed in this ticket:  nrf52840 Bluetooth and 802.15.4 multiprotocol example project from 4 years ago. But now are you saying there's a complete 802.15.4 stack built into zephyr which we could use?

[Edvin]

Hello,

Thank you! The file made me realize I struggled with including the overlay file using VS Code. however, I got it working with the command line. 

So I see the same as you. Using 2x nRF52840 DKs, I can receive the messages (at least for a while before it freezes. Do you see that the receiver freezes as well?)

But when I try the nRF53 DK I see the following being printed in the log every time the transmitter transmits:

uart:~$ [00:30:10.783,874] <dbg> net_ieee802154_frame: ieee802154_validate_fc_seq: (rx_q[0]): fs(1): 0/1/0/0/1/0
[00:30:10.783,905] <dbg> net_ieee802154_frame: ieee802154_validate_fc_seq: (rx_q[0]): fs(2): 1/0/1/2/1 - 108
[00:30:10.783,874] <dbg> net_ieee802154_frame: ieee802154_validate_fc_seq: (rx_q[0]): fs(1): 0/1/0/0/1/0
[00:30:10.783,905] <dbg> net_ieee802154_frame: ieee802154_validate_fc_seq: (rx_q[0]): fs(2): 1/0/1/2/1 - 108

Do you see the same?

I am not sure, but I suspect it has something to do with the nRF53 being dual core, and the interrupts not being forwarded correctly. It is not a sample that we provide, and it doesn't support the nRF53 DK out of the box (it is not listed under compatible boards when you configure your build), but I will forward these projects internally, and hopefully, the guys working on our Thread or Zigbee stack, who knows the 802154 stack a little better than I do, can have a look. I will keep you posted when I hear anything.

Best regards,

Edvin

[Richard]

Two github repos created for the TX and RX projects - should make it a bit easier to follow than the dropbox link

https://github.com/richardpike/nrf_802154_tx_HW

https://github.com/richardpike/nrf_802154_rxclient

these include configuration jsons. I've pulled these down and built cleanly using VS code, but the overlay file was pointing to a place in appdata local so manually changed that - not sure what's going on there.

I only have 1 nRF52840DK so can't fully test that way today. Using the 5340 (of which I have 3 DKs) that's not what I see "ieee802154_nrf5: Packet dropped by NET stack" is printed by the receiver each time the tx transmits.

Difference perhaps due to it being a command line build? Not sure why that should make a difference though...

Can you let me know exactly what you entered in the command line to build please?

Best regards,
Richard

[Edvin]

Hello Richard,

To build using the command line I used the command:

west build -b nrf5340dk_nrf5340_cpuapp -d build_53 -- -DOVERLAY_CONFIG="overlay-802154.conf"

Richard said:

I only have 1 nRF52840DK so can't fully test that way today

That is fine. I have created an internal ticket, so I will let you know when I hear something.

You didn't end up adding any configurations like CONFIG_IEEE802154_RAW_MODE=n in your project that I can tell, right?

BR,
Edvin

[Richard]

Thanks.

Edvin said:

You didn't end up adding any configurations like CONFIG_IEEE802154_RAW_MODE=n in your project

No, haven't tried doing that since the initial creation of the ticket. Our existing libraries which use a combination of the old thread and zigbee SDK and nRF radio driver made use of the non raw functions.
If it becomes necessary to use the raw functions then we'll just update them as required.

BR,
Richard

[Edvin]

Hello Richard,

I got a reply from our IEEE guys. They wrote:

--------------------

I've managed to get it to work both on nRF52 and nRF53, but before I will jump to the explanation, I would like to emphasize that the customer is NOT using the nrf802154_raw API as intended. The first couple of bytes of the "p_data" buffer is passed to the "nrf_802154_transmit_raw" function should be the data length and the +IEEE802.15.4 MAC header + . When using the raw API, the header is not filled out by the radio driver (with the exception of some fields), and the idea of the API is that the header is provided from the outside. Instead, the customer sets the first byte to the data length and then immediately to the payload ("Hello world"). I am not sure if we can guarantee that for some input data in such form the driver won't fall into some strange state or change the data. Also, this makes the frame non-IEEE802.15.4 compliant. 

However, the reason why the samples work on nRF52 but not on the nRF53 is that the user uses the "nrf_802154_received_raw" function as a callback for a received freame. The fact that this function is a callback is probably some legacy code - it might be deleted in the future and the sample would then stop working alltogether. The "nrf_802154_received_timestamp_raw" callback (which with the given configuration isimplemented in "ieee802154_nrf5.c") should be used instead. By implementing this function on the nRF52 the user "steals" the callback from the ieee802154_nrf5.c". However, on the nRF53 the "nrf_802154_received_raw" callback is no longer called by the radio driver, so the function implemented by the user will never be called, and instead, the received frame is processed in ieee802154_nrf5.c". 

To make the sample work as the user intended (without fixing the issue with the incorrect p_data pointer), the following should be done (in both samples):

1) In prj.conf, delete all the lines starting with "CONFIG_NET" and "CONFIG_NETWORKING=y" - they are causing processing of the received 802.15.4 by zephyr drivers, which makes using the raw API impossible.

2) Add includes at the top of the echo-client.c" file:

// Some comments here
#include "nrf_802154.h"
#if defined(CONFIG_NRF_802154_SER_HOST)
#include "nrf_802154_serialization_error.h"
#endif

3) At the bottom of the file include this code (this will intitialize the driver during kernel startup and implement the "nrf_802154_serialization_error", needed for nRF5340):

static int init_802154(const struct device *dev)
{
	nrf_802154_init();
 
	return 0;
}
 
#if defined(CONFIG_NRF_802154_SER_HOST)
void nrf_802154_serialization_error(const nrf_802154_ser_err_data_t *err)
{
	__ASSERT(false, "802.15.4 serialization error: %d", err->reason);
}
#endif
 
// The magic number 80 is set to the same value as the default of CONFIG_IEEE802154_NRF5_INIT_PRIO
SYS_INIT(init_802154, POST_KERNEL, 80);

4) Replace the "nrf_802154_received_raw" function:

void nrf_802154_received_raw(uint8_t * p_data, int8_t power, uint8_t lqi)

with

void nrf_802154_received_timestamp_raw(uint8_t * p_data, int8_t power, uint8_t lqi, uint64_t time)

5) When building the samples, do it with this command: (note that -DOVERLAY_CONFIG="overlay-802154.conf" must not be used)

"west build -b nrf52840dk_nrf52840 -d build -- -DCONFIG_NRF_802154_RADIO_DRIVER=y"

and

"west build -b nrf5340dk_nrf5340_cpuapp -d build – -DCONFIG_NRF_802154_SER_HOST=y -D802154_rpmsgCONFIG_NRF_802154_RADIO_DRIVER=y"

------------------------------------

Perhaps you can give this a try, and let me know whether it works.

Best regards,

Edvin

[Richard]

Hi Edvin,

Thank you for getting back to me with this. Completely understand about the incorrect use of the MAC header, even after removing the header from my work project the same issue was present, so felt the more simplified a sample the better.

I've made the edits in both projects but unfortunately they both have build errors for both the 52840 and 5340

For the 52840

d:\WorkspaceVSCodeGitHub\nrf_802154_rxclient\src\echo-client.c:77:35: error: expected ')' before numeric constant
77 | SYS_INIT(init_802154, POST_KERNEL, 80);

I've used SYS_INIT previously without issues so rather confused by that one.

5340

d:\WorkspaceVSCodeGitHub\nrf_802154_rxclient\src\echo-client.c:25:10: fatal error: nrf_802154.h: No such file or directory
25 | #include "nrf_802154.h"

I get these errors whether it uses command line of VS code to build.

For additional info:

I've got both projects in this directory:

D:\WorkspaceVSCodeGitHub
The SDK is located here: D:\NCS\v2.2.0

and the command line build I've run from this location D:\NCS\v2.2.0\zephyr is:

for 5340 

west build --build-dir d:\WorkspaceVSCodeGitHub\nrf_802154_rxclient\build_5340_term d:\WorkspaceVSCodeGitHub\nrf_802154_rxclient --pristine --board nrf5340dk_nrf5340_cpuapp -DCONFIG_NRF_802154_RADIO_DRIVER="y" -D802154_rpmsgCONFIG_NRF_802154_RADIO_DRIVER=y

52840
west build --build-dir d:\WorkspaceVSCodeGitHub\nrf_802154_tx_HW\build_52840_term d:\WorkspaceVSCodeGitHub\nrf_802154_tx_HW --pristine --board nrf52840dk_nrf52840 -DCONFIG_NRF_802154_RADIO_DRIVER="y"

Equivalent changes for relevant project names. Feels like I'm missing something very simple.

BR,
Richard

[Øyvind]

Hi Richard, 

Edvin is currently out of office. I will forward your answer to our IEEE guys. 

One thing I do note from the west build commands included is that they are missing a double dash "--" in front of -DCONFIG_NRF_802154_RADIO_DRIVER=y

How did you add this line to your build?

Kind regards,
Øyvind

[Richard]

Hi Øyvind,

Thank you, I added the double dash but get the same errors on both projects.

When building via VS code I've added "-- -DCONFIG_NRF_802154_RADIO_DRIVER=y" in to Extra CMake arguments.

The command lines done from the SDK zephyr location with the projects in a different directory.

KR,

Richard

[Richard]

Hi Øyvind,

Øyvind said:

I will forward your answer to our IEEE guys. 

Nearly 2 weeks now, what is the update please? 2 months after raising this ticket and still no resolution.

Richard

[Edvin]

Hello Richard,

I will ping our IEEE guys on our internal ticket. 

BR,
Edvin