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

[Edvin]

Hello Richard,

I saw your message, but I don't think it would help much to set up a call. I need to look up these things, and find people who can answer, because I myself am not familiar with the content of, or how to use, the 802154 drivers in nrfx_drivers or zephyr. Unfortunately, we don't have any in our support department that are, so we need to do it the way we currently are. I need to find the correct person to forward your questions to. 

Richard said:

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.

Is it possible to send the two projects that you are using, so that I can have a look, and see if I can figure out why the callback is not triggering? If you have any confidencial information in the projects, you can strip them out, as long as I can use them to trigger (and not trigger) the callbacks.

BR,
Edvin

[Richard]

Hi Edvin,

The coordinator software I'm currently using is on a different module and the firmware is definitely not available to be sent.

I'm trying to do a simple send receive version between two nrFs that should work similarly enough to highlight the problem. I hope to send that through tomorrow.

BR,

Richard
P.S. thank you for the explanation on PM

[Richard]

Hi Edvin,

I've managed to strip down two simple projects, one uses the raw transmit function to simply send "Hello World" in a loop, and the other should be listening, but it always prints out "Packet dropped by NET stack".

Here's a link to download

https://www.dropbox.com/t/RkI3Qd4A59Ek7YH2

This is the entire project with the build directories - I'm not sure what should be ignored.

I have two nRF5340-DK devices that are V2.0.0

I can see the packets using the nRF52840 Dongle V1.0.0 with wireshark

I'm not sure why but this doesn't appear to receive at all using the 52840 dev kit I have - possibly stripped something out I shouldn't have, but the 5340 message remains the same and that's what I was hoping to fix.

Thank you,

BR,
Richard

[Richard]

Hello,

I've had no response on this for 12 days, but in that time 2 separate e-mails to tell me someone has been assigned.

Any updates please?

Richard

[Edvin]

Hello Richard,

I am very sorry for the late reply. I will do my best to prioritize this ticket. I will run your project tomorrow (It is currently 10:30pm, and I am at home. I need to be in the office to run it on 2xnRF5340 DKs.

I am sorry for the inconvenience.

Please be aware that I can't guarantee that I can give you a final answer tomorrow, but I will at least give you an update. A custom 802.15.4 stack is not something that we officially support, but I will do my best to figure out why the nRF5340 doesn't receive the callbacks.

Best regards,

Edvin