- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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__,
});
Solved! Go to Solution.
- Tags:
- cyw20719b2
- hci uart
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello;
Wondering if you have any update on this topic?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, ... checking in again to see if there is any feedback on this issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Checking again to see if you have any suggestions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.