Hi,

We want to use the CYBT-343151-02 (based on the CYW20706 chipset) for two simultaneous SCO connection. How does the PCM slot mapping works ? The CYW20706 datasheet says that the slot is always mapped to the same slot, but it does not give a rule for it :

1/ Do the first SCO connection uses the first slot, then the second SCO uses the next slot ?

2/ If I understand correctly, if the first SCO connection is closed while the other is still in use, then the second SCO data will still be placed on the second slot. Is it correct ?

3/ Is the slot mapping based on the SCO connection creation order or using a fixed scheme (like based on the remote device bd address or anything else) ?

Regards, Jerome

Hi,

While looking for topics and knowledge database to use the CYBT-343151-02 bluetooth module, I found various entries :

* The knowledge database KBA225450 indicate a procedure to start the CYW2070*-A2 based devices (and list the one I'm using) in HCI mode, where all Bluetooth HCI standard commands are available. The interesting part is the SPI2_MOSI signal which must be setup correctly to 'force' the HCI mode when the device has an embedded firmware (which is the case for the CYBT-343151-02 module which is factory programmed with the EZ-Serial firmware).

* This blog article (https://community.infineon.com/t5/Resource-Library/Run-CYW20706-in-HCI-Mode/ta-p/246397) also gives a method to enter HCI mode on the same chipset, but the method is different (this time, the UART CTS pin must be pulled to HIGH during power up to enable HCI mode).

* This topic (https://community.infineon.com/t5/Studio-Bluetooth/CYBT-333047-02-via-HCI-interface-on-Raspberry-Pi/td-p/124669) seems to confirm my observations that I will try to describe bellow.

All tests bellow have been done on a CYBT-343026-EVAL board where the chipset has been replaced with the CYBT-343151-02.

* TEST 1 : With stock firmware (EZ-Serial), the device will most of the time not accept HCI commands (we still have a setup where it seems to work but depends on timings).

* TEST 2 : With stock firmware and CTS pulled high (as per  blog article), the behavior is almost the same as with the firmware running (I've observed that the HCI UART RTS stays high after a few seconds, therefore the configuration of the module via HCI H4 is stopped)

* TEST 3: With the stock firmware and only SPI2_MOSI pulled to ground during boot, then the HCI reset command is accepted (using cybluetool), other commands are not acknowledged. Seems like this is the download mode described in the datasheet of the module, the airoc hci protocl manual and the CYW20706 datasheet).

* TEST 4: With the stock firmware, CTS set HIGH and SPI2_MOSI set LOW during power-on (press the recovery button while plugging the USB cable), then all HCI commands are accepted (in the limit of the chipset HCI supported commands). I can do almost all configuration, but the device is not discoverable nor can detect other device (even after using the 'enable radio' vendor command in cybluetootl).

* TEST 5: Same procedure as TEST4, with bluez hciattach/hcitool utilities (to workaround the problem described in the third listed entries at the top of this topic, I've just send a HCI reset command to the module using cybluetool before running the hciattach command, because a hcidump told me that the module was not accepting the commands, and during the numerous tests that I did, I saw that this was due to a missing HCI reset command). This test ends in the same way as the TEST 4, event after sending the radio enable command, I can't detect other devices and the device can't be discovered.

* TEST 6: Using the empty_wiced_bt example from the ModusToolbox software, the HCI interface works (using cybluetool to enable scan, and radio, or using the bluez tools). I can discover the device, do an inquiry

Questions are :

* Why do the device need a firmware to run to make the bluetooth really work ? Is it related to the patched that the firmware embeds (and which might configure the radio properly, which is not the case when the firmware is bypassed using the SPI2_MOSI / CTS pin forced levels) ?

* Can you confirm that the ROM code needs both SPI2_MOSI and CTS pins to be forced to specific levels to boot in HCI mode (or tell me why this is needed, if it is not related to the CYW20706 ROM) ?

* Is there any way to make the module work using HCI commands and the stock EZ-Serial firmware ?

Regards, Jerome

We have a device using CYBT-343026 module with EZ-Serial Firmware.  During initialization the application calls gap_get_device_name to set some application specific name.  Using a typical Android BLT scanner/pairing app the device appears in the scan list with the device name that was set by the application.  When an attempt is made to pair with the device the name shown in any pairing pop-up boxes is of the form "EZ-Serial E8:B9:12_BT" rather than the device name.

Is there a way to get the pairing operation to use the device name rather the default "EZ-Serial..."?