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?

[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

[Edvin]

How do you build the project, and do I need to do something in order to transfer the messages, or do they start automatically once both devices are switched on?

I tried building using "west build -b nrf5340dk_nrf5340_cpuapp -- -DCONF_FILE="overlay-802154.conf" ", but it fails with:

C:/Nordic_Semiconductor/SDKs/ncs/my_projects/2.1.2/customer/echo_client_rx/src/echo-client.c:23:10: fatal error: nrf_802154.h: No such file or directory
   23 | #include "nrf_802154.h"

(Using NCS v2.1.2, both on the transmitter and the receiver)

What command did you use to build the applications? Or did you use VS code? If so, what does your build configuration look like? If you use ninja directly, please let me know all the commands you used to build. 

BR,
Edvin

[Richard]

Thank you Edvin,

Once they're built nothing needs to be done, just see the nrf terminal output for the messages. I built both projects using VS Code.

Both build configs are set up like this:

FYI I noticed that the new release candidate of the SDK was using zephyr 3.2 which no longer requires IP so ran this test there but the same message occurs.

This should probably be in a new ticket - but where does the build config setup get saved so that it I could have included that in the files sent? Best guess is it'll be part of the VS Code workspace file?

BR,

Richard

[Edvin]

Richard said:

This should probably be in a new ticket - but where does the build config setup get saved so that it I could have included that in the files sent? Best guess is it'll be part of the VS Code workspace file?

You can right click on the build "folder" in VS Code, and select "Save configuration as preset", which will create a .json file in your application folder. If you create a new build configuration in a project folder where this .json file is present, you will get the option to generate from that preset. 

However, your echo-client.c has, on line 23:

#include "nrf_802154.h"

but the compiler doesn't know where to pick it up from. Did you copy this file and paste it somewhere in your NCS repository?

Can you please try to build it in a pristine version of NCS to see if you get the same error?

Or can you upload your .json file?

BR,

Edvin

[Richard]

I've not done anything with the nrf_802154.h file manually. I've just done a pristine build on the 2.2.0rc on my laptop which I installed yesterday so no updates and that was fine.

JSON file type not allowed as attachment apparently, but this is the code:

{
    "version": 2,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 20
    },
    "configurePresets": [
        {
            "name": "build_5340_802154",
            "displayName": "Build for NRF5340 DK NRF5340 application MCU",
            "generator": "Ninja",
            "binaryDir": "${sourceDir}/build_5340_802154",
            "cacheVariables": {
                "NCS_TOOLCHAIN_VERSION": "NONE",
                "BOARD": "nrf5340dk_nrf5340_cpuapp",
                "BOARD_ROOT": "${sourceDir}/",
                "CONF_FILE": "${sourceDir}/prj.conf",
                "OVERLAY_CONFIG": "${sourceDir}/overlay-802154.conf"
            }
        }
    ]
}

I'll spend a bit of time putting this into a github repo as it might be a bit easier

[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