MPSL Signal blocked

[rdebrum-cdi]

Hello,

I am running this on 2 different boards and experiencing the same issue on boath

I am very interested in the NCS implementation of this app, and I have downloaded and got it to build with NCS version 2.3.0. I did not run into any major issues in this porting process. I am curious if you have seen the following issue - when I build and flash to the NRF52 DK (nrf52832), and then press button 1, I see:

I also downloaded this and ported it to work with the nrf5340 DK. This was quite the process but I also got some help in a private ticket on DevZone with Sigurd Olav Nevstad in private case ID #293529 (in case you can see this). When flashing to the nrf5340 DK, I also see the issue of MPLS TIMESLOT BLOCKED.

I have not been able to overcome this and I did not see anyone else having this issue. How can I overcome this, or how can I share this code with you to see if you or others have the same issue?

Thanks,

[rdebrum-cdi]

I want to post an update here - I found that commenting out the line of code in main.c main() that starts advertising allowed me to avoid this issue for both boards.

I now am able to see the nrf52832 act as described in the README. When I press button1 on the nrf52832DK, the gpio starts toggling @ 1000 Hz. The nrf5340 now fails to react to these packets. The code is hard faulting in the nrfx_gppi.h file (line 590 - the task endpoint asserts because it is likely 0).

I am curious if there are any efforts to make this sample work for the nrf5340, or if there are any pointers you might have for making this work for the 5340.

Thanks

[charles-gilliland]

@rdebrum-cdi Hi, I'm also trying to port this code to work with the 5340, specifically on the NET core (empty application core). I had to do a lot of refactoring in time_sync.c - mostly changing ppi functions to their dppi and/or gppi equivalents (at least i think they are equivalent).

I also got that hard fault in nrfx_gppi.h line 590, but I simply commented out any spot in time_sync.c where the functions had '0' as arguments such as nrfx_gppi_fork_endpoint_setup(chn[1], 0); There are several of these kinds of functions throughout time_sync.c. As far as I can tell the old calls didn't have an assert, while the new ones do.

Like you, I commented out the advertising in main() to get rid of the MPSL signal blocked errors, but the GPIO is not toggling on either of my DK's. Further, I am getting a new hard fault which only occurs on the non-beaconing DK, but unfortunately this fault doesn't come with a line number :(

So far I've been naively refactoring and hoping for the best, but I fear there could be some underlying peripheral incompatibilities that I'm not aware of...

Did you have any further luck with this?

[rdebrum-cdi]

@charles-gilliland Hey, glad to hear I am not the only one pursuing this endeavor. I have managed to reach really low current draws on the nrf5340 promising long battery life for several projects, so it makes sense to me to accomplish this task on the nrf5340 so that more people can enjoy the low power.

Visibility is not great when this firmware is running so I don't have much information on how or why but I managed to get a GPIO to toggle on my nrf5340 DK. However, it is not synchronizing with a 52DK right next to it, and I need to let it run for over a minute after I press btn1 before it toggles.

Maybe you have boiled the issues down to the same 2 problems I found.

The major thing I did was change all calls from nrfppi to nrfxgppi. This was relatively straightforward, though I came across 1 function for which there was no direct translation: nrf_ppi_channel_and_fork_endpoint_setup(). I worked around this by translating it into 2 function calls: nrfx_gppi_channel_endpoints_setup() and nrfx_gppi_fork_endpoint_setup(). This seems to be the trick.

Of course I also ran into the issue that you have of passing 0's into tep or fep or eep in varying function calls. It appears that on the nrf52 boards, it is acceptable to pass in a 0 for a fork or task or event endpoints to clear them. However, for the nrf5340, I too get errors when trying to do this. In my research, I think I can attribute it to the complexity of dppi - setting a 0 does not clear the endpoint. Instead, you pass in the specific endpoint which gets referenced and then 0'ed out. I may be wrong but this is my working theory.

How I plan to keep progressing (unless someone wiser can guide me) is to refactor and keep better track of what endpoint to clear. For example, instead of using nrfx_gppi_endpoint_setup(chn, 0), I need to use nrfx_gppi_endpoint_clear(chn, eep) where eep was the last event endpoint that was set up on that channel.

This is lengthy but it is my current understanding. Perhaps we can share code at some point, though it sounds like we are on the same track!

[charles-gilliland]

@rdebrum-cdi We are definitely on the same track!

After struggling with this for a while, I went back and read the documentation for MPSL and found what I believe to be the root issue. I made a post on DevZone, where I explain it as follows:

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.

Due to time constraints I had to abandon this effort and just use a 52840, but I'm positive that this functionality could be implemented on the 5340, just not so easily. Seems to me like a significant amount of rework would be required, and you're right in saying that the visibility isn't great - it's extremely difficult to debug when all of the important stuff is happening inside hardware peripherals like TIMER and PPI...

[nordic-auko]

Hi, I've not been able to spend significant time on this code base for the past year due to other priorities, but finally was able to push an update to add support or nRF5340 net core using DPPI. The functionality should be the same, but the timer adjustment procedure is simplified somewhat by using the TIMER "one shot" functionality available in nRF530