nRF5340 Wireless Timer Synchronization

RE: nRF5340 Wireless Timer Synchronization

Maria Gilje — Mon, 05 Feb 2024 08:46:59 GMT

Hello,

Many NCS samples is supported on nRF5340. You can check if the sample is supported by reading the table in the documentation for any of the nrf samples in NCS. As an example, this is the table for the Bluetooth: Peripheral LBS sample:

If you are looking for samples made specifically for the nRF5340 you can find the overview for those here in the NCS documentation.

The source code for the samples is found on GitHub, and you can install the SDK by following the instructions in the Installation guide.

Best regards,

Maria

RE: nRF5340 Wireless Timer Synchronization

lvh831 — Sat, 03 Feb 2024 03:36:34 GMT

Hi Maria, is there a sample code for nrf53 with ncs? Thanks.

RE: nRF5340 Wireless Timer Synchronization

Maria Gilje — Thu, 05 Oct 2023 06:49:20 GMT

Hello again,

The feedback I got was that porting to the nRF53 should be possible as long as there are enough DPPI and and EGU instances available. You can use the Instantiation table to find out. For the timesync demo the requirements are found here.

BR,

Maria

RE: nRF5340 Wireless Timer Synchronization

Maria Gilje — Mon, 02 Oct 2023 13:13:53 GMT

Hello,

I was able to get some comments on this, and that it could be possible to make the sample work on the nRF5340. I will get back to you very soon with the details.

Edit (03.10.23): due to unexpected circumstances I did not have the time to provide the details today. Thank you for your patience.

BR,

Maria

RE: nRF5340 Wireless Timer Synchronization

charles.gilliland — Thu, 28 Sep 2023 13:35:49 GMT

Maria, thanks for your response. I understand that you might not know the answers right away - it's taken me quite a while to wrap my head around all of this. Really I am trying to figure out whether porting this application to the 5340 is worth the time and effort (if it is even possible in the first place), when I could just use a 52840 and have it work immediately.

And just to clarify I am using NCS v2.4.2, not the nRF5 SDK. I've been able to get the application to build, but I am having runtime kernel panics. I did have to make some changes to get the code to compile using v2.4.2, but I don't have any 52-series dev kits to try it out on.

The original post by Audun says that "Note that this could be simplified to use only one additional timer, as TIMER0 can be used within timeslots to trigger the radio as well." This is encouraging, but the post is from 2016 and I can see where the code has changed since then, so I wonder if this is still true...

I have seen this post, Shared timer on nRF5340 between NET and APP CPUs?, which is also a bit old but could be useful.

Please let me know if you have any updates, and I will do the same!

RE: nRF5340 Wireless Timer Synchronization

Maria Gilje — Wed, 27 Sep 2023 16:39:17 GMT

Hello Charles,

I can see that you have put a lot of thought into this already, which you have included in your ticket. I will try to address everything.

[quote user=""]Over the past few days I have been trying to port this sample application to work on the nrf5340 NET core, but I am starting to think that it's not possible.[/quote]

I'm not sure if the sample is portable to the nRF5340. I want to ask the developer of the sample application, but they are not available for several weeks. I will try to find out if someone has taken over the responsibility while they are away.

[quote user=""]

According to its documentation, MPSL gives the application "exclusive and real-time access" to TIMER0, and TIMER1 for the nRF53 series. This is not an issue with the 52840 for example, since the application can instead use TIMER3 and TIMER4. However, the 5340 NET core only has 3 timers, and since MPSL owns both TIMER0 and TIMER1, there is only 1 timer available for the application to use.

Am I correct in saying this?

[/quote]

Yes, you are correct. Though a tiny detail is that for nRF52xxx, only TIMER0 is used, so TIMER1 is also available for other uses than MPSL on nRF52xxx.

For the nRF5340, the network core indeed has only three TIMERs, which only leaves one to be used by the application when MPSL is initialized. The application core also has three TIMERs, and it could be possible to share one of the TIMERs from the application core with the network core. If you want to try, you can check out this older case for how to do this with registers: nRF5340 Shared Peripherals between APP and NET cores Note that the case is from before NCS v2.0.0 and the introduction of pinctrl, which could have an impact on implementation.

[quote user=""] If so, are there any equivalent sample applications that demonstrate high-precision synchronization between two nRF5340's?[/quote]

I don't think there is any in NCS, but I can ask my colleagues if any of them know of any.

[quote user=""]I have experimented with the nrf_dm sample, which must be doing some kind of synchronization, but I don't need distance measurement, just time sync... Would it be possible to strip down this sample application to only give me gpio sync signals?[/quote]

I am not experienced with the Distance measurement sample myself, so I will contact my colleagues to ask for input on this. But logically it seems a bit backwards to kind of generalize a specialized sample. Then again, it depends on how specific the synchronization is in the DM sample, and I don't know that.

[quote user=""]I've also ported periodic_adv and periodic_sync to work on the 5340, but I have no idea where in the code the actual synchronization occurs, and thus where in the code I could toggle the GPIO pin...[/quote]

You're getting a lot of "I don't know"s from me today, but I will find out if these can be a starting point for you. If you want, you could also ask the Zephyr community about this. They can be reached in the Zephyr Project's Discord server through this invite. Let me know if they have a quick answer for you.

[quote user=""]I'm a bit discouraged at the moment, and thinking about using a 52840 paired with another microcontroller for my application instead of the 5340, but I'd really rather use the 5340 since it would be a one-chip solution.[/quote]

I hope that we can find a solution which meets your wishes and needs.

Best regards,

Maria