Hello CYW20706 wizards,
I'm developing the app code to use the chip in embedded mode. The app is going to communicate with a host through the HCI UART, but the UART channel is noisy and unreliable. I'm attempting to use the raw mode so that I can add checksum to the WICED HCI protocol, and also in case the message length is corrupted, add receive message timeout so that subsequent transmission is not mistaken as part of the corrupted message.
So far I'm testing with the "hci_audio_gateway" demo app and the host "client_control" program. My first goal is to get raw mode to work and make the demo app perform exactly as before. I modified the transport data callback to detect and segment received bytes into separate WICED HCI messges, and return the number of bytes processed as instructed by the comments on top of the wiced_tranport_data_handler_t definition. When I tried to use the "open port" button on the "client_control" program, the app call back was call once with 18 bytes, made up by 3 WICED HCI commands sent by the host. I then saw traces indicating the commands was processed by the command handler hci_control_proc_rx_cmd(). Then the communication stopped and no more traffic traces were logged. I debugged the host app and the problem seemed to be the WICED HCI event responses generated by the app were not transmitted properly to the host.
So here are some specific questions about the raw mode:
1) Should the transport data call back return the number of bytes processed? The call back provided in the demo app hci_control_proc_rx_cmd() returns executing status, contrary to the instructions provided on top of the wiced_tranport_data_handler_t definition
2) How does raw mode work for transmitting packets to the host? Are functions wiced_transport_send_buffer() and wiced_transport_send_data() to be used the same as in WICED_TRANSPORT_UART_HCI_MODE?
3) What triggers a call to the transport data handler? I'm assuming either after x bytes received, or some fixed timeout after the first byte is received? If so, what is x and the timeout?
4) Is wiced_transport_tx_complete_t callback only called when a packet is sent using wiced_transport_send_buffer()? And the only purpose of it to release app allocated buffer?
One long shot question:
1) In WICED_TRANSPORT_UART_HCI_MODE, if the message length is corrupted, will the app (library code) give up on the packet after a timeout? I'm assuming no and enough bytes have to be transmitted by the host for the app to resume communication.
//My data call back provided below just in case
static uint32_t transport_data_cb( uint8_t *p_data, uint32_t length )
static uint8_t packet_buffer;
static uint32_t packet_index = 0;
static uint32_t packet_len = 0;
WICED_BT_TRACE("***** transport rx: n=%d\n", length);
for(i=0; i<length; i++)
if(packet_index == 0 && p_data[i] != 0x19)
//Dump invalid start byte
WICED_BT_TRACE("***** transport rx: dumped byte %x\n", p_data[i]);
//Save to buffer
packet_buffer[packet_index++] = p_data[i];
if(packet_index == 5)
packet_len = packet_buffer | (packet_buffer << 8);
WICED_BT_TRACE("***** transport rx: got packet len=%d\n", packet_len);
if(packet_index >= 5 && packet_index == packet_len + 5)
WICED_BT_TRACE("***** transport rx: got full packet, i=%d\n", i);
packet_index = 0;
packet_len = 0;