Zephyr: hci_uart not acknowledging data correctly / losing packets

[jjamesson]

Hi, Zephyr community,

Problem
I am experiencing issues when trying to create an embedded application for the hci_uart FW controller running on NRF52810. The issue is that I'm trying to send 10 packets to the controller, but I only get 10 acknowledgements back very rarely. The number, in fact, varies depending on how how many/how long packets I send. For this example, In most cases, the number of ACKs I get is 9.

The way I'm doing this is such that the host assumes that the controller has 3 buffers (in fact it has 8). So I first fill 3 buffers, and then wait for an acknowledgement before sending the next one.

I have tried various ways of changing data length or number of packets, connection parameter settings, and much more. I'm beginning to run out of ideas. It could be something obvious I might not be aware of. Hope you can help.

With regards,
James

Additional notes

• This problem does NOT occour when I when I only enqueue 1 packet instead of 3
• If I send longer packets, even more data gets lost
• I have tried this with DLE and 2M PHY
• The two communicating devices are right next to each other
• Host RTS is always 0
• Host CTS is always 0
• UART speed is 1M
• The controller is configured to have 8 RX/TX buffers
• NRF Sniffer shows that only 9 packets do indeed get sent out
• The other device on the receiving end also receives 9 packets
• There is around 20 us pause between two sequential UART writes.
• I have tried this on both Zephyr 2.3.99 and 1.14

To Reproduce
Steps to reproduce the behavior:

• Send 3x data packets
• Wait for ACK
• Send 1 data packet
• Wait for ACK
  ...
• Wait for ACK
• Send last data packet
• Wait for ACK (3x)

Expected behavior
I do indeed get 10 acknowledgements back.

Attachments
I have attached some files that will help get a clearer picture:

• NRF sniffer log
• hci_uart controller configuration file
• uC UART output/input log
• Oscilloscope image (where you can indeed see 10 data packets and 9 ACKs)

[carlescufi]

@jjamesson

(cc @cvinayak, @joerchan and @nordic-krch)

Could you please provide the following information:

1. hci_uart is running on an nRF52810, is this a dev kit or a custom board?
2. Where are you running the Host, i.e. the HCI "client"?
3. Are you using a debugger chip via USB or do you have a physical connection TX <-> RX and RX <-> TX between 2 ICs directly?
4. You seem to be disabling hardware flow control, can you confirm that? If you are doing that then data may be lost.
5. When you say "ACK" you mean HCI Number of Completed Packets?

[jjamesson]

Hi, @carlescufi ,
Thanks for reaching back. The answers to your questions are the following:
1) The Nrf52810 is running on a custom board
2) The host is an STM32 Cortex-M4 chip running on the same board. I am currently developing a custom FW for the host.
3) The two IC-s are situated on the same board, and have a physical UART direct connection between them.
4) Not intentionally, although I find it weird, that if I drive RTS high on the host, the controller doesnt abide to that and still sends me data. Also, CTS is never high. Although I have configured CONFIG_BT_HCI_ACL_FLOW_CONTROL=y in the controllers conf file. Am I missing something?
5) Correct.

With regards,
James

[nordic-krch]

@jjamesson hardware flow control for uart is enabled in DTS. CONFIG_BT_HCI_ACL_FLOW_CONTROL is just an information to the hci that flow control is enabled.

overlay should contain something like this to enable flow control:

&uart1 {
    hw-flow-control; /* if not defined in DTS */
        rts-pin = <5>; /* if not defined in DTS */
    cts-pin = <7>; /* if not defined in DTS */
};

[joerchan]

BT_HCI_ACL_FLOW_CONTROL is not UART hardware flow control. It is flow control in receiving data packets and sending them from the controller to the host.

[jjamesson]

Thank you for all the replies and helping me clear out the meaning of BT_HCI_ACL_FLOW_CONTROL. Especially for @nordic-krch for even pointing out a solution. This helped me solve the problem.

With regards,
James