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

[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