RE: Gzll fifo handling

astella — Thu, 02 Apr 2020 09:20:21 GMT

Hi Kenneth, thank you for you kindness.

I have got a freertos task that is doing gzll work. So, workaround is checking continuously fifo in the gzll dedicated thread loop, it is like a polling to check fifo. Not a particular trigger, in this case. This polling seems to prevent any troubles, at least in my case.

About your second question, I'm going to check with a step by step debugging and calling nrf_gzll_get_total_allocated_packet_count before and after reception routines, to see if I can immediately see an effect on rx fifo.

Yes, tx buffers on the host is going to be full, at least in my case, I can get nrf_gzll_ok_to_add_packet_to_tx_fifo error printed on a serial port, and it is about that moment that host cannot communicate anymore with one of the two devices, when not using workaround. I'll try to print a more complete report using serial port, so that it can be useful to describe what happens.

I want to try to theoretically find a succession of events that can block communication, reading in documentation what is default tx rx behavior.

I'll also give a look to ack lenght, as you kindly suggested and I'll update here.

Thank you very much

RE: Gzll fifo handling

Kenneth — Wed, 01 Apr 2020 13:16:37 GMT

Hi,

Your workaround seems good, but I am unsure what might trigger it yes. It seems to be related to the host based on your description.

So based on your description it seems that calling gzp_crypt_user_data_read() / nrf_gzll_fetch_packet_from_rx_fifo() have no effect to the buffer? Or is the problem that TX buffers on the host is going full?

Is it possible that you are writing too large packets (length field is wrong) from the host to the device?

Best regards,
Kenneth