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.

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