Using the NRF52840 Zephyr applications with Renode

[BChetty]

Hi, I am currently evaluating the NRF52840 for our applications which will be deployed in underground mines across South Africa.

I see that Nordic has a good relationship with Zephyr and Renode as shown in the post below:

     https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/developing-and-testing-ble-products-on-nrf52840-in-renode-and-zephyr 

My goal at this stage is to evaluate the Openthread protocol with the NRF52840 however when I compile the Zephyr Echo_Server/Client with the openthread overlay or the ieee802.15.4 overlay, I notice that no packets are being sent to the NRF52840 radio as shown by Wireshark on Renode.

If you have any insights as to why this is, or any suggestions on configuring the Zephyr application (Echo_Server/Client) to work on Renode (with 802.15.4 / Openthread), please advise me.

I tested the Zephyr application on 2 physical nrf52840dk devices and that was successful, i.e. Two-way communication was established using openthread or regular 802.15.4.

I need to test on Renode as this will enable me to test a large number of devices which will be required for our application.

My Zephyr Echo_Server prj.conf is as follows:

# Generic networking options
CONFIG_NETWORKING=y
CONFIG_NET_UDP=y
CONFIG_NET_TCP=n
CONFIG_NET_IPV6=y
CONFIG_NET_IPV4=n
CONFIG_NET_CONFIG_NEED_IPV4=n
CONFIG_NET_CONFIG_NEED_IPV6=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_POSIX_MAX_FDS=6
CONFIG_NET_CONNECTION_MANAGER=y
CONFIG_NET_CONNECTION_MANAGER_LOG_LEVEL_INF=y

# Kernel options
CONFIG_MAIN_STACK_SIZE=12288
CONFIG_ENTROPY_GENERATOR=y
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_INIT_STACKS=y

# Logging
CONFIG_NET_LOG=y
CONFIG_LOG=y
CONFIG_NET_STATISTICS=y
CONFIG_PRINTK=y
CONFIG_NET_MGMT_EVENT_LOG_LEVEL_DBG=y
CONFIG_NET_CONNECTION_MANAGER_LOG_LEVEL_DBG=y
# Network buffers
CONFIG_NET_PKT_RX_COUNT=16
CONFIG_NET_PKT_TX_COUNT=16
CONFIG_NET_BUF_RX_COUNT=64
CONFIG_NET_BUF_TX_COUNT=64
CONFIG_NET_CONTEXT_NET_PKT_POOL=y

# IP address options
CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=6
CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=4
CONFIG_NET_MAX_CONTEXTS=10

# Network shell
CONFIG_NET_SHELL=y
CONFIG_SHELL=y

# Network application options and configuration
CONFIG_NET_CONFIG_SETTINGS=y

CONFIG_NET_CONFIG_MY_IPV6_ADDR="fdde:ad00:beef::2"
CONFIG_NET_CONFIG_PEER_IPV6_ADDR="fdde:ad00:beef::1"


# Number of socket descriptors might need adjusting
# if there are more than 1 handlers defined.
CONFIG_POSIX_MAX_FDS=10

# How many client can connect to echo-server simultaneously
CONFIG_NET_SAMPLE_NUM_HANDLERS=2


CONFIG_FLASH=n
CONFIG_OPENTHREAD_SETTINGS_RAM=y
#~ CONFIG_OPENTHREAD_FULL_LOGS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_NET_IPV6_NBR_CACHE=n
CONFIG_NET_IPV6_MLD=n
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
# Enable OpenThread shell
CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_STACK_SIZE=4096
CONFIG_NET_L2_OPENTHREAD=y
CONFIG_OPENTHREAD_DEBUG=y
CONFIG_OPENTHREAD_L2_DEBUG=y
CONFIG_OPENTHREAD_L2_LOG_LEVEL_INF=y
CONFIG_OPENTHREAD_CHANNEL=26
CONFIG_OPENTHREAD_NETWORKKEY="00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff"

Regards

Brenton

[Christian Anton]

Hi there,


I am having similar requirements and troubles while trying to set up a reusable CI development container based on snippets from nrf-docker, zephyr-docker and renode-docker.

What I could figure out so far:
Building the BLE heartrate sample
* (z) produces printk-uart output in renode with setup west init --mr "v3.1.0"
* (n) but does not when having setup west init -m github.com/.../sdk-nrf --mr "v2.1.0" (or v2.0.2)

Furthermore, simply building the hello_world sample produces printk output with both setups (z) and (n). But as soon as you set prj.conf -> CONFIG_BT=y then the simulated image build with (n) has no more output.

When comparing the build outputs we get
* (z) Zephyr version: 3.1.0-rc1 (/zephyrdev/zephyr) and
* (n) Zephyr version: v3.1.99-ncs1 (/zephyrdev/zephyr) respectively

So I am assuming that there might be some nRF-specific customization to the Zephyr source code which creates BLE-incompatibilities in renode.

I'll keep you posted if I can figure out some more.

Cheers,

Chris

[Susheel Nuguru]

Thanks for the info Christian, The (z) and (n) results are very interesting. 

It would be also interesting to know which Bluetooth LE Controller you have been using?

[Christian Anton]

Yes, definitely!

Sorry for the late response. From tomorrow onward and the next weeks I'll be focusing again on this topic. Hence, any time. I guess you have access to my email address. FYI: The demo now runs in an interactive docker container whose "one-click" install I am willing to share after some generalization.

Cheers,

Chris

[BChetty]

Hi Christian, glad to hear you got the ble sample working via docker. Have you tested the 802.15.4 stack on Renode by any chance?

[Christian Anton]

Not really. Since you asked I've compiled and run the echo server example within Renode. At least some printk output can be seen.

FYI: I've bundled the "one-script" install here if you'd like to experiment. With this you could also create two west repositories like I did above. For this exchange ...

./run west init .. --mr $ZEPHYR_SRC_VER

with

./run west init .. -m github.com/.../sdk-nrf --mr v2.1.0

[BChetty]

Thank you. I will definately look into it.

[Susheel Nuguru]

Thanks for this Christian, I will try to run your demo on my end aswell. it is great to see that you have BLE working.

[Christian Anton]

Hi you two,

did you have the chance to reproduce for an arbitrary BLE example a working (z) and a non-working (n) run?

FYI: I am currently forced to move forward with the Zephyr-only BLE stack to have any chance of working in continuous integration style.

[BChetty]

Hi Christian. Regarding BLE, I could only utilze P2P connections such as the heartrate samples in Zephyr (Central_HR and Peripheral_HR). I used the main Zephyr Repo with Renode. I assume the mesh BLE samples do not work due to unimplemented Registers in Renode.

[BChetty]

For some reason, when I attempt to use the Nordic Zephyr samples for 802.15.4 or BLE, Renode seems to get stuck in an endless resetting cycle

[Christian Anton]

Thanks for trying it out! And yep, that pretty much sums up what I also experienced.

Maybe in Nordic's Zephyr fork there are other registers used which renode did not implement yet. According to this blog "keeping a very clean fork of Zephyr, almost free of downstream changes" it should be a tiny detail which Susheel Nuguru might have heard of.

All-in-all what we are trying here seems to be the bleeding-edge :) Especially when you consider the many warnings you get with a working renode run.

[BChetty]

I agree :)  That many warnings on a working sample makes it really daunting to tackle actual issues with the platform. It would be nice if the Renode developers could have pointed us in the right direction. They don't seem to respond to issues posted on their GIT repo.