cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

hmk_4648636
New Contributor

test board : CYW989820EVB-01 (CYW89820)

When sending data to the board using hci uart, the board stop if the length is shorter than the header(5byte) or the actual length does not match.

As shown in the capture below, a large amount of unknown data may be transmitted.

pastedImage_0.png

The same thing happens when I insert an error handling code under that condition. Is there any way to solve it?

0 Likes
1 Solution
DheerajPK_41
Moderator
Moderator

Hi,

The CONNSTATUS_CMD_LENGTH is an argument of WriteFile() function, and it indicates the number of bytes to be written. Ideally, it should be the size of the buffer (ie, SystemCfgCmd) that holds the data to be written. When you set CONNSTATUS_CMD_LENGTH greater than the size of SystemCfgCmd, the writeFile() might be writing some junk value to the I/O device (ie, hComm). I believe, this problem should be handled at the VisualStudio app side.

Coming to the embedded side: The device will check only the command formatted in the SystemCfgCmd. CYW20xxx uses the 5-byte packet header for command/event exchanges with the host MCU as mentioned in the WICED-HCI-Control-Protocol.pdf​.  If these 5 bytes are proper then the device recognize the command and executes.

For example, if you send the bytes "0x19 0x01 0x00 0x00 0x00" to the HCI UART,  the device will get reset. (provided the embedded app should be configured to receive the WICED_HCI commands)

0x19 -> packet type

0x01 -> command code

0x00 -> group code

0x00 0x00 -> packet length

I don't recognize the command which you have shown in the picture. (ie, 0x19 0xC0 0xFF 0x03 0x00 0x01 0x02 0x03). Could you please explain it?

0xFF is the group code of HCI_CONTROL_GROUP_MISC.

pastedImage_31.png

And I don't know if it's related to this problem, but the reset button of evb doesn't work when the command window is opened.

When the WICED HCI port is opened, the CTS line is in asserted state. So when you press and release the reset button, the device goes to the download mode. It won't perform the reset process. Please check  WICED-HCI-Control-Protocol.pdf​  for more into.

Please let me know if you have any queries.

Thanks,

-Dheeraj

View solution in original post

6 Replies
AnjanaM_61
Moderator
Moderator

Hi hmk_4648636 ,

What type of HCI command or host tool are you using ?

You should give the data as per the length defined in the HCI command packet you are sending, other wise it may give a error response.

Could you please provide more details?

Regards,
Anjana

DheerajPK_41
Moderator
Moderator

Hi hmk_4648636 ,

Could you please provide us the steps to reproduce this issue?

Which WICED HCI command were you using? 

Thanks,

-Dheeraj

hmk_4648636
New Contributor

AnjanaM_61DheerajP_41

Sorry, answer was late.

My board communicates with programs coded in Visual Studio.

I send the command using only the group code 0xFF.

My board communicates with a program coded in Visual Studio as shown below.pastedImage_1.png

If the lengths match, there is no problem.

However, if I send a command that does not match the actual length as shown below, the board stops. The following command is not accepted.

=>When the size is larger than the actual length.

=>When sending a length smaller than the header(5byte).

The error handling was as follows, but it was the same.

pastedImage_1.png

And I don't know if it's related to this problem, but the reset button of evb doesn't work when the command window is opened.

Is there any way to solve these problems?

I want you to let me know what I did wrong.

(Please excuse my poor English..T-T)

0 Likes
DheerajPK_41
Moderator
Moderator

Hi,

The CONNSTATUS_CMD_LENGTH is an argument of WriteFile() function, and it indicates the number of bytes to be written. Ideally, it should be the size of the buffer (ie, SystemCfgCmd) that holds the data to be written. When you set CONNSTATUS_CMD_LENGTH greater than the size of SystemCfgCmd, the writeFile() might be writing some junk value to the I/O device (ie, hComm). I believe, this problem should be handled at the VisualStudio app side.

Coming to the embedded side: The device will check only the command formatted in the SystemCfgCmd. CYW20xxx uses the 5-byte packet header for command/event exchanges with the host MCU as mentioned in the WICED-HCI-Control-Protocol.pdf​.  If these 5 bytes are proper then the device recognize the command and executes.

For example, if you send the bytes "0x19 0x01 0x00 0x00 0x00" to the HCI UART,  the device will get reset. (provided the embedded app should be configured to receive the WICED_HCI commands)

0x19 -> packet type

0x01 -> command code

0x00 -> group code

0x00 0x00 -> packet length

I don't recognize the command which you have shown in the picture. (ie, 0x19 0xC0 0xFF 0x03 0x00 0x01 0x02 0x03). Could you please explain it?

0xFF is the group code of HCI_CONTROL_GROUP_MISC.

pastedImage_31.png

And I don't know if it's related to this problem, but the reset button of evb doesn't work when the command window is opened.

When the WICED HCI port is opened, the CTS line is in asserted state. So when you press and release the reset button, the device goes to the download mode. It won't perform the reset process. Please check  WICED-HCI-Control-Protocol.pdf​  for more into.

Please let me know if you have any queries.

Thanks,

-Dheeraj

View solution in original post

hmk_4648636
New Contributor

DheerajP_41​, Thank you for answer.

0x19 0xC0 0xFF 0x03 0x00 0x01 0x02 0x03

=> I tested to perform different functions depending on the value in place of Command/ Event Code.

This is the last question.!

So what should I do if garbage value is transferred?

For example, if a value that is completely unrelated to the header packet is transmitted(ex. 0x01, 0x02, 0x03), the board stops and the next normal activity cannot be performed. Is there any way to handle errors against the garbage value?

Thank you.

0 Likes
DheerajPK_41
Moderator
Moderator

Hi,

The host connected over UART should be friendly; i.e. is not interested to break our device. If the device hangs, we may indeed try fixing the bug on the MCU side by not sending bad message.

Thanks,

-Dheeraj