“WICED_TRANSPORT_UART_RAW_MODE” for CYW20706

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

cross mob
LJYe_2922526
Level 5
Level 5
25 likes received 10 likes received 5 likes given

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.

Thanks!

//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[512];

    static uint32_t packet_index = 0;

    static uint32_t packet_len = 0;

    WICED_BT_TRACE("***** transport rx: n=%d\n", length);

    uint32_t i;

    for(i=0; i<length; i++)

    {

        if(packet_index == 0 && p_data != 0x19)

        {

            //Dump invalid start byte

            WICED_BT_TRACE("***** transport rx: dumped byte %x\n", p_data);

        }

        else

        {

            //Save to buffer

            packet_buffer[packet_index++] = p_data;

           

            //Get length

            if(packet_index == 5)

            {

                packet_len = packet_buffer[3] | (packet_buffer[4] << 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);

                hci_control_proc_rx_cmd(packet_buffer+1, packet_len+4);

                packet_index = 0;

                packet_len = 0;

            }

        }

    }

    return i;

}

1 Solution

For others viewing this thread, yes raw mode is supported by the usual transport APIs, but the RX handler must behave differently than the WICED_HCI RX handler (return bytes read instead of SUCCESS, and do not try to free transport buffer). A sample app will be included in future releases to demonstrate the steps necessary.

lye_2922526, We have already addressed your issue internally: I wrote a sample application that fully implements raw mode that was provided to you over email by your FAE. We plan to release this sample app into the SDK in future releases.

To answer (3): a watermark level triggers the callback.

Jacob

View solution in original post

9 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

There shouldn't be an issue with using the WICED_HCI protocol to accomplish CRC checks on the packets. You will just have to take into account the packet header which the transport layer is constructing on your behalf when cacluating your CRC. Then attach the CRC to the end of the packet and the receiving side will have to deconstruct based on the same information. For this, you will have to analyze the exact WICED_HCI packet construction as found in hci_control_api.h:

pastedImage_0.png

The APIs to properly use the _raw_ HCI interface were intentionally removed from the SDK. See below.

Jacob

Hi Jacob,

Sorry I accidentally hit replay on the previous comment.

I thought about using the HCI transport mode and add in CRC. But what if the length field is corrupted? Unless the SDK has timeout built in for receiving a single packet, the UART will become unresponsive until enough bytes are transmitted.

Thanks,

LJ

I created a test project today and found out if the first byte (Packet Type) is not HCI_WICED_PKT (0x19 or 25), the embedded app just stops responding. Tx stops. Rx cannot be resumed no matter how many additional bytes I transmit. Is there a way for the host MCU to reset the Transport UART?

What are you sending when the device stops responding?

Jacob

As soon as I send any byte that is not 0x19 after a complete WICED HCI message, the embedded app (audio gateway demo) stops responding. Sending more bytes or waiting for the app to recover do not work.

LJYe_2922526
Level 5
Level 5
25 likes received 10 likes received 5 likes given

In HCI mode code still breaks if the first byte of a packet/transmission is not 0x19.

Regarding the raw mode, here are the answers to my original questions:

  1. In data callback return number of bytes processed instead of SUCCESS
  2. wiced_transport_send_data() and wiced_transport_send_buffer() do not assemble the WICED HCI packet anymore and only send payload raw
  3. Still working on this one. Would be nice to know how the stack works.
  4. tx complete callback is only called when using wiced_transport_send_buffer()

We are implementing our own protocol so we have to use the raw mode. I'm puzzled by the previous answer stating API for the raw mode was removed. Is the mode going to be supported by future WICED studio releases?

For others viewing this thread, yes raw mode is supported by the usual transport APIs, but the RX handler must behave differently than the WICED_HCI RX handler (return bytes read instead of SUCCESS, and do not try to free transport buffer). A sample app will be included in future releases to demonstrate the steps necessary.

lye_2922526, We have already addressed your issue internally: I wrote a sample application that fully implements raw mode that was provided to you over email by your FAE. We plan to release this sample app into the SDK in future releases.

To answer (3): a watermark level triggers the callback.

Jacob

Thanks Jacob for writing the sample app, it helped a lot. I just wanted to shared what I learned from the sample code.

You guys are the only life line we developers have. Without your support our lives would be much much harder.

Just one last question for question 3): If less than watermark amount of bytes are received, is there a timeout for releasing the bytes and trigger callback?

Anonymous
Not applicable

To my knowledge and testing, even if the 20706 receives a single byte of data over the UART, then the callback is triggered. You will have to return the number of bytes that you processed. If you processed only some part of the data, then the rest of the data can be accessed when the callback is triggered the next time.

In other words, the watermark is 1 byte.