Gazell goes to disabled state, but no call to disable it.

[Philip Freidin]

I'm using the example code for simple device/host Gazell in SDK 7.1.0 as my starting point for my application.

My program runs for a second or two, then ends up in the callback function nrf_gzll_disabled().

Since I don't have any calls to nrf_gzll_disable() and I also don't call nrf_gzll_set_auto_disable() , I don't understand what is causing Gazell to disable. The problem seems to be related to an interrupt handler that takes too long to execute. I expected this might have lead to loosing sync, but having Gazell disable itself is unexpected, and not documented.

Please make the sources for the Gazell protocol available, so I have a chance at debugging these types of problems. I understand why the SDs don't have sources available, but I don't see any point in the SDK being a mixture of with and without source.

[Asbjørn]

Have you made sure that your application interrupt have lower priority than those that are used by Gazell? Gazell must have highest priority and if you have set the same interrupt priority level for your application, you might end up blocking Gazell. So make sure you set your application interrupt level to level 1 or lower as Gazell use level 0.

[Philip Freidin]

Hi Asbjørn, thanks for looking at this. I may well have the priorities both at 0, and your explanation that this can lead to Gazell being blocked makes sense. I would expect the result of that would be that Gazell just looses sync, and when it is no longer blocked, it will just take longer to re-establish the link, through its normal channel hopping protocol. What I am seeing though is that Gazell disables itself. What you have not addressed are my main two points: (1) Gazell goes to the disabled state which is not documented anywhere for the conditions I describe, and (2) my request that the source of Gazell be made available, just as it was with nRF24LE1. Thanks.

[Asbjørn]

To answer your questions:

1. It shouldn't go into a disable state as you report. We haven't seen this behavior before, so there might be something else sent as error message from gazell as well? Do you get any other error messages? Are you using some of the HW/peripherals that's required by Gazell? Especially ppi channels? It's not normal behavior that gazell disables itself, that's why we suspect it to be related to other parts of the code accessing ppi channels, interrupts or other peripherals that's forcing gazell to lock up and hence disable.

2. The source code for gazell is not planned to be released. So I don't have any good news for you in that sense.