Hi everybody,
as already mentioned in the title, I guess to have stumbled across an incompatibility between the app_pwm library and the gazelle link layer.
To keep it short, the only observeable issue was that the rssi reading in the nrf_gzll_host_rx_data_ready callback´s rx_info.rssi parameter went completely haywire, showing different values in the debugger than underlying checks against constants returned, for example debugger states that the value of rx_info.rssi is 0x63 but rx_info.rssi <= -60 returning true.
After playing around with optimization and the nrf_log library it always printed rx_info.rssi as being 0.
I believe, after conducting some research, that this may be a conflict, or resource reuse bug, connected to the PPI Channels used bei the gazelle link layer and app_pwm.
As documentation states, gazelle uses ppi channels 0, 1 and 2 (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fgzll_02_user_guide.html) but app_pwm somehow allocates these dynamically and in my case, uses the exact same ppi channels. I already tried change the order of initializing both components but app_pwm simply ignores that the lowest three ppi channels are already in use by the gazelle link layer.
As of writing I have not figured out a good workaround for this, but I´ll keep on trying. I´m also curious if anybody else came across this issues or is able to reproduce it as I couldn´t find anything regaring this. The only topic I found which looks similar is this one (https://devzone.nordicsemi.com/f/nordic-q-a/3473/rssi-value-using-gazell), but it is five years old and I can´t say for sure if it has the same reason.
Best Regards
Pascal
