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