Studio Bluetooth Forum Discussions

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;

}

Hi,

We observed XO_IN A4 pin load to our reference clock input (supplied from oscillator or function generator).

1.8Vp-p signal becomes ~1.2Vp-p when connected to XO_IN pin of Cypress chip. See attached waveforms of reference clock without and with connections.

We would like to know from Cypress support team what could be reason for loading effect on input reference clock. We tried reference clock from oscillator and function generator, observations are same.

Thank you,

Pravinkumar

Hi,

we are using the 20705 device for s STB design and i'm wondering where to find the actual patchram files former delivered by broadcom with the netapp package.

Can anyone shed some light into this?

Best Regards,

Andy

Hi,

Every command a host sends to CYW20706 / 07 starts with 0x19. There is a function "uint32_t hci_control_proc_rx_cmd( uint8_t *p_data, uint32_t length )" to handle various commands received over UART. I would like to know where in the code the CYW20706 / 07 makes sure that the first byte is 0x19.

Please point me to the appropriate code.

Thank you,

Pravinkumar