• State Not Answered
  • Replies 6 replies
  • Subscribers 71 subscribers
  • Views 1220 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 315292
Options

nRF5340 Wireless Timer Synchronization

charles.gilliland

Hello,

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.

I have been successful in getting it to compile after many changes, mostly changing ppi funcion calls to their corresponding dppi or gppi calls. During this process I also had to change which timers are used, and this is what I think the inherent incompatibility is.

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? If so, are there any equivalent sample applications that demonstrate high-precision synchronization between two nRF5340's?

My end goal is to be able to synchronize sensor data acquisition wirelessly. I think toggling a GPIO pin is a good place to start, since this would allow me to measure the delay between two rising/falling edges, thereby evaluating the precision of synchronization.

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?

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

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.

Please let me know if there are any more samples, or any ideas as to how I might go about implementing time sync on the 5340.

Parents
  • 0

    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.

    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.

    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.

    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?

    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. 

    If so, are there any equivalent sample applications that demonstrate high-precision synchronization between two nRF5340's?

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

    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?

    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.

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

    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.

    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.

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

    Best regards,

    Maria

  • 0 in reply to Maria Gilje

    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!

  • 0 in reply to charles.gilliland

    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

Reply Children
Related