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]

I am not familiar with the 802.15.4 drivers. They are usually just used by the Thread or Zigbee stack, so that is why I have not looked directly at the 802.15.4 API.

I asked a colleague of mine about this, and he referred to the same samples that you referred to. 

He said:

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

I would start with the echo_server and the echo client samples with overlay-802154.conf, but these are using 802.15.4 with IPv6, not sure if that is what he is looking for. There is also

https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/net/wpan_serial

which might be more relevant, but it may be a bit difficult to test without a Linux device. I don't think that we have any other samples using 802.15.4 without using Thread or Zigbee.

Otherwise I would recommend to use Zephyr's 802.15.4 API directly, and not the nrf radio driver (nrf_802154_...).

Please see:

https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/net/ieee802154.h
and
https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/net/ieee802154_radio.h

or even higher layers that would provide ephyr's 802.15.4 MAC features, like association:

https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/net/ieee802154_mgmt.h

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

So do you have any idea of what sort of 802.15.4 driver you need?

BR,

Edvin

[Richard]

We're trying to implement a beaconless 802.15.4 stack. It also needs to be multiprotocol with BLE

I've updated the client example to send some packets using the nrf_802154_transmit_raw function to our existing coordinator to try and associate and send data - it works on a 52840DK (with the exception of acks not being enabled on it - not immediately clear how to do that at the moment), and when I request data it's coming through to me via nrf_802154_received_raw

But it doesn't work properly on a 5340DK, the receive data doesn't come through and I get: "Packet dropped by NET stack". Which on debugging shows me the point of failure is here: 

if (!net_if_flag_is_set(iface, NET_IF_UP)) {
    return -ENETDOWN;
}

within net_core.c

This leads us to https://stackoverflow.com/questions/72180227/does-zephyr-support-sending-non-ip-traffic-over-802-15-4 which appears to confirm we can't use the zephyr stack as we don't want to do it via IP

BR

Richard

[Edvin]

I see. So no IP, then.

Ok, so let us say that you want to include nrf_802154.c and nrf_802154.h to your project. Don't you agree that you would need to set NRF_802154_USE_RAW_API to 1? 

Make sure that it is set to 1 in both files called nrf_802154.h, both in modules\hal\nordic\drivers\nrf_802154\driver\include\nrf_802154_config.h and in nrfxlib\nrf802154\driver\include\nrf_802154_config.h (I don't know which one that is used). Are you then able to use the function nrf_802154_transmit_raw() from your main() function?

Are you able to include the nrf_802154.h file in your project?

BR,
Edvin

[Richard]

Hi Edvin,

I've managed to include those files. NRF_802154_USE_RAW_API is always set to 1 which has meant I've updated a couple of our legacy functions to use nrf_802154_transmit_raw rather than nrf_802154_transmit which isn't an arduous task - we were just wondering if it could be avoided which was the initial reason for this ticket. (We're actually still not sure how to do this, but it's less important now).

I've found that on both the 52840 and 5340 the raw transmit function works. But on the 5340 I can't receive anything - it doesn't get to this function.

void nrf_802154_received_raw(uint8_t * p_data, int8_t power, uint8_t lqi)
{
    LOG_HEXDUMP_DBG(p_data, 27, "received from TT base");
}

it fails here: zephyr\drivers\ieee802154\ieee802154_nrf5.c on line 190

I attempted to compare the difference by debugging the 5340 and 52840 at receive time, but the 52840 doesn't break in the function like the 5340 does.

As an aside, do you use the private message functionality on this site? I haven't received a response.

BR,

Richard