Delay from Data on HCI UART to RX Interrupt?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

We are using the HCI UART of the CYW20719B2 chip in Raw Mode.   We have the communication working , but have noticed that there is a delay of ~ 50ms from when data is placed on the CYW20719's RX Pin to when the RX Interrupt is registered with the Application-Level code (i.e. the callback handler registered at: wiced_transport_cfg_t.p_data_handler ).  This amount of delay seems excessive and is impacting the responsiveness of our system.

What controls the delay from the Hardware Block to the Application Level, ... and can this delay be reduced?

These are our configurations for the HCI UART:

wiced_transport_init(&(wiced_transport_cfg_t) {
.type = WICED_TRANSPORT_UART,
.cfg = {
.uart_cfg = {
.mode = WICED_TRANSPORT_UART_RAW_MODE,
.baud_rate = M_HCI_UART_BAUD_RATE (230400),
},
},
.rx_buff_pool_cfg = {
.buffer_size = RX_BUFFER_SIZE (2000),
.buffer_count = RX_BUFFER_COUNT (2)
},
.p_data_handler = m_hci_uart_rx_handler__,
.p_status_handler = m_hci_uart_status_handler__,
.p_tx_complete_cback = m_hci_uart_tx_complete__,
});

0 Likes
1 Solution
DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

Update:

This delay of ~50ms is expected based on the current architecture. But we have taken your feedback seriously and communicated with the FW team. We will try to optimize it in the future release.

View solution in original post

0 Likes
8 Replies
DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

Hi,

Increasing the baud rate will definitely increase the speed. 

May I know which is your host system? Please share the steps to reproduce the issue and we will try to check whether any modification needed to handle the delay in the lower layers of the stack.

Thanks,

-Dheeraj.P.K

0 Likes
lock attach
Attachments are accessible only for community members.
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

Hello;

I have already tried several different Baud rates and it does not affect the observed delay.  

In our design, we do not really have a 'Host System', the CYW20179B2 communicates to a chip from another vendor that provides W-Fi functionality and which acts as a 'peer' device, so all messages that are sent over the HCI UART to the CYW20719B2 are directed to the application code and so do not interact with the WICED BT Stack.

You can observe the delay if you load and run the "UART Raw Mode" Sample Application that is available through ModusToolbox (no change necessary).  I have included two screen captures from a Logic Analyzer that was attached to the HCI UART RXD and TXD, PUART TXD, and WICED_P26 when running this sample application.  (I have used WICED_P26 as a 'signal' for when the 'data_rx_cback' function is invoked, when the function is entered, I set WICED_P26 low and on exiting, I set it high again, ... a code snip is attached)

As you can see from the captures, Some data is sent on HCI_RXD (I  used a UART Terminal Program on a PC to send some ASCII characters), then there is a delay of ~49.6ms from the end of the Data to when 'data_rx_cback' is entered (when WICED_P26 goes low).  At the same time you can also see that some output is started on the PUART. 

The Second plot I have attached is the same set-up but with the HCI UART Baud rate set to 460800.  

In our own application, I see EXACTLY the same delay (~49.6ms) from the end of any data sent by the Wi-Fi peer device, to when our own data handler is invoked.  The fact that the delay is almost exactly the same between the Example code and our application code, makes me suspicious that there is some timer acting behind the scene.  As I mentioned, this delay seems excessive and is causing some responsiveness issues for us.

0 Likes
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

Hello;

Wondering if you have any update on this topic?

0 Likes
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

Hello, ... checking in again to see if there is any feedback on this issue?

0 Likes
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

Checking again to see if you have any suggestions.

0 Likes
anveshj
Level 1
Level 1
First reply posted First like given Welcome!

There is nothing wrong with your RX ISR().
Your LED function is fine too. As a general rule you avoid calling functions from inside an ISR(), but something like RX is not going to be very frequent. i.e ms rather than us.

I suspect that you have another IRQ that you do not service properly. Post the smallest amount of code that exhibits the problem.

0 Likes
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

@anveshj If you read my reply from March 17, you can see that I clearly state that this issue is observable in the 'UART RAW Mode' sample application made available through ModusToolBox, ... the only modification necessary is to toggle a GPIO pin in the UART RX Handler to act as a physical signal for when the handler is called.  

 

0 Likes
DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

Update:

This delay of ~50ms is expected based on the current architecture. But we have taken your feedback seriously and communicated with the FW team. We will try to optimize it in the future release.

0 Likes