Gazell for nRF5340

[Petri Haavisto]

I am trying to run Gazell libraries on nRF5340. There have been some previous posts about this with answers either saying that the support does not exist, might be coming, or that it should be possible to compile the libraries also for nRF5340 even though the Gazell current samples are not for that platform.

SDK 2.6.1 Gazell libraries (quite new) fail to compile for nRF5340 at least due to PPI vs DPPI issues.

However, this change note from SDK 2.1 indicates that support for nRF5340 should already exist (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0-rc2/nrfxlib/gzll/CHANGELOG.html). The note says that "Added the library variant for the nRF5340 network core."

Since the code still does not compile I guess that the comment means that a pre-compiled library has been added (compiled from some other sources). And indeed, the SDK does include the Gazell library libgzll.a for nRF5340. But how can I take that into use in a practical way? Some other libraries have KCONFIG options to select a pre-compiled library instead of building from sources, but I did not find any such option. I am using the VS code environment of the SDK and would really hope to find a simple solution which does not include hacking the build scripts.

[ovrebekk]

Hi Petri

Did you try to build for the network core or the application core? 

The radio is only available from the network core, and you need to build the Gazell application for this core specifically. 

Best regards
Torbjørn

[Petri Haavisto]

Hi,

I am building for the network core (target nrf5340dk_nrf5340_cpunet).

I am attaching the build output from VS Code extension below (I did not find a way to make an attachment so the text is pasted at the end of this message). It has a bunch of gcc errors due to PPI vs DPPI which is already in compilation, apparently due to nRF5340 being different in this respect. I don't know if there would be some other problems later also since the build stops at these gcc errors.

Petri

[ovrebekk]

Hi Petri

I tried building it myself and see the same issue. It seems there is a lib provided for the nRF5340 netcore, but the gzll_glue layer does not support DPPI, which is required by the nRF5340. 

I will do some digging internally and try to figure out what the plans are for supporting Gazell in the nRF5340 properly. 

Best regards
Torbjørn

[Petri Haavisto]

Thank you!

If Gazell on nRF5340 is not happening I would be grateful of any tips about alternative *equally simple* 2.4GHz radio solutions (not BLE) that might exist as samples for nRF5340. For example, if there would exist some simple proprietary protocol for exchanging data packets with acknowledgement.

Petri

[ovrebekk]

Hi Petri

I did some digging internally, and it seems there was an attempt at some point to patch the gzll_glue layer to support the nRF5340, but this wasn't followed up properly and as such was never merged into the official repositories. At the moment there doesn't seem to be any plans to properly support Gazell in the nRF5340. 

As an alternative, have you had a look at the ESB library?

ESB is essentially the lower layer protocol upon which Gazell is based, and supports the same type of addressing, ACK, ACK payload and retransmit mechanism. What it doesn't support is frequency jumping and device/host synchronization, and this would have to be added yourself if you need it. There is no proper pairing and encryption library for ESB either, like there is for Gazell. 

The upside of using ESB is that you have more flexibility with regards to the payload length and packet timing, and you also have full access to the source code in case you want to make changes to the underlying protocol. 

In addition to the official ESB PTX and PRX samples in the SDK you might also want to have a look at the sample below, which shows how ESB can be run in parallel with BLE using MPSL and timeslots, and also shows how you can establish communication between the appcore and netcore in order to have the ESB communication triggered from the appcore (the ESB code itself will always have to run on the netcore):
https://github.com/too1/ncs-esb-ble-mpsl-demo

Best regards
Torbjørn

[Petri Haavisto]

Hi,

ESB looks quite suitable for my purposes and I will try that!

This is clear now. Thanks!

Best regards,

Petri

[ovrebekk]

Hi Petri

Good to hear that you can use ESB as an alternative. The best of luck with your project

Best regards
Torbjørn