9 Replies Latest reply on Jan 18, 2018 3:23 AM by sujayy_46

    “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706

    LJYe_2922526

      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[i] != 0x19)

              {

                  //Dump invalid start byte

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

              }

              else

              {

                  //Save to buffer

                  packet_buffer[packet_index++] = p_data[i];

                 

                  //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. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
          JacobT_81

          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:

           

           

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

           

          Jacob

          1 of 1 people found this helpful
          • 2. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
            LJYe_2922526

            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

            1 of 1 people found this helpful
            • 3. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
              LJYe_2922526

              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?

              1 of 1 people found this helpful
              • 4. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
                JacobT_81

                What are you sending when the device stops responding?

                 

                Jacob

                1 of 1 people found this helpful
                • 5. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
                  LJYe_2922526

                  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.

                  1 of 1 people found this helpful
                  • 6. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
                    LJYe_2922526

                    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?

                    1 of 1 people found this helpful
                    • 7. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
                      JacobT_81

                      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

                      2 of 2 people found this helpful
                      • 8. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706
                        LJYe_2922526

                        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?

                        1 of 1 people found this helpful
                        • 9. Re: “WICED_TRANSPORT_UART_RAW_MODE” for CYW20706

                          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.

                          2 of 2 people found this helpful