大佬们好!
我在使用CYW 20706模块调试AVRCP协议时(IDE ModusToolbox, bt_sdk 2.5),调用avrc_app_pass_through(uint16_t handle, uint8_t op_id,uint8_t state)函数控制音量,函数反馈“WICED_SUCCESS”,但手机端音量无变化,更换多个手机测试无果。调试过程AVRCP协议连接正常,上/下曲、播放/暂停等功能都正常。
手机端关键LOG:
D Avrcp_ext: Avrcp current play state: 2 isMusicActive: false A2dp state: 11 Cached passthrough command: 0
W Avrcp_ext: Passthrough non-media key 65 (code 24) state 0
D Avrcp_ext: cached passthrough: 0current passthrough: 24
W MediaSessionService: Attempted to dispatch null or non-media key event.
V Avrcp_ext: Exit handleMessage
我查看了Android的KEYCODE定义,KeyEvent.KEYCODE_VOLUME_UP = 24.
请问导致这个问题的原因可能有那些?是否存在解决的方法?
Show Less
Hi,
I am using the CYW20819EVB-02 board and I am trying to enable notifications with web ble
https://googlechrome.github.io/samples/web-bluetooth/notifications.html
https://googlechrome.github.io/samples/web-bluetooth/read-characteristic-value-changed.html
I keep getting errors, even though enabling notifications work fine with the cypress app on mobile.
Is there something I am missing? (do i need to respond to the start notification?)
Any help would be greatly appreciated
Thanks in advance!
Show LessI'm using a CY8CPROTO-063-BLE board. When I try to initialize the BLE ECO clock, Cy_BLE_EcoConfigure() returns CY_BLE_ECO_HARDWARE_ERROR. The proximate cause is a time-out waiting for the BLE_BLESS_MT_STATUS.BLESS_STATE bit to be set, at line 409 in cy_ble_clk.c.
I have previously had BLE working in both Central Device and Peripheral roles, on two different copies of the board, and both boards now display the same behavior, so it's unlikely actually to be a hardware error. It's almost certainly a configuration problem, but I have no idea where to start looking.
/* Wait for BLESS in ACTIVE state */
while(((BLE_BLESS_MT_STATUS & BLE_BLESS_MT_STATUS_BLESS_STATE_Msk) == 0U) && (timeout > 0U))
{
timeout--;
Cy_SysLib_DelayUs(CY_BLE_DELAY_TIME);
}
if(timeout == 0U)
{
status = CY_BLE_ECO_HARDWARE_ERROR;
}
Any suggestions would be appreciated.
Thanks,
-Nick
Show LessI have been facing the problem that spp_scb.flow_control_on never revert back to FALSE on high-load operation.
It occurs in rare cases when receiving and transmitting are performed at same time.
In this case I cannot transmits data any more.
I'd like to get the information about how to fix it or how to poll flow status.
spp_scb.flow_control_on is set in the following callback.
Is there a possibility that the callback vanishes into nothing?
void spp_port_event_cback(wiced_bt_rfcomm_port_event_t event, uint16_t handle){
if(event & PORT_EV_RXCHAR){
<*snip*>
}
if(event & PORT_EV_FC){
spp_scb.flow_control_on = !(event & PORT_EV_FCS) ? WICED_TRUE : WICED_FALSE;
}
if(event & PORT_EV_TXEMPTY){
spp_scb.flow_control_on = WICED_FALSE;
}
spp_scb.event_error = (event & PORT_EV_ERR) ? 1 : 0;
return;
}
This thread is created for tesing, editing the thread
Hello,
I receive over SPP a batches of bytes larger than 256 (varying between 81 bytes and 800 bytes per batch with max 1000 bytes per second). By HCI tracing I was able to see that the byte batches received completely.
This batch should be send to an external MCU by use of PUART (without HW handshake). The PUART is set up properly and tested okay on 115k and 38400 baud.
I am using in the callback function from SPP spp_rx_data_callback the buffer-pointer p_data and the buffer length data_len to send the by wiced_hal_puart_synchronous_write(p_data, data_len) it appears that large batches are not transferred correctly, say for batches larger than 256 bytes the maximum number of bytes transferred is around 256.
For batches smaller than 256 bytes (say 242) I get the correct 242 bytes plus some additional from the begin of the buffer plus some that are not assignable.
Is there a limit of 256 bytes in the TX buffer ?
Or is there a limit in the SPP reception buffer ?
How can I send securely these number of bytes?
WICED_BT_TRACE("###############################\n");
WICED_BT_TRACE("%s handle: %d len: %d %02x-%02x\n", __FUNCTION__, session_handle, data_len, p_data[0], p_data[data_len - 1]);
WICED_BT_TRACE("###############################\n");
wiced_hal_puart_print("\n########## BEGIN #############\n");
wiced_hal_puart_synchronous_write(p_data, data_len);
if (data_len>0)
{
wiced_hal_puart_synchronous_write(p_data, data_len);
}
wiced_hal_puart_print("\n########## END #############\n");
Show LessCan someone modify the Handsfree or headset snip in Modus 2.2 to demonstrate PCM out and PCM in for the 353027-EVAL board?
I've been trying but unsuccessfully to get this to work.
Show LessHello guys,
I have a custom board with cyw20719b2, with a build setup using modus toolboox 2.1 and wiced bt sdk v2.7.1 fdb3982. As this is a custom board for embedded environment, the host is not really connected.
I have sleep configuration like this:
wiced_sleep_configure(
&(wiced_sleep_config_t) {
.sleep_mode = WICED_SLEEP_MODE_TRANSPORT,
.device_wake_gpio_num = WICED_P28,
.device_wake_mode = WICED_SLEEP_WAKE_ACTIVE_HIGH,
.device_wake_source = WICED_SLEEP_WAKE_SOURCE_GPIO,
.host_wake_mode = WICED_SLEEP_WAKE_ACTIVE_HIGH,
.sleep_permit_handler = m_shutdown_handler,
}
);
Here in the sleep configuration WICED_P28 is connected to interrupt pin coming from PMIC (Which gives push button / charger connect etc interrupts coming from PMIC).
So my problem is that, I also need the WICED_P28 pin for GPIO interrupt to handle various interrupts coming from PMIC.
When I tried to configure WICED_P28 for both (wiced_sleep_configure() & wiced_hal_gpio_register_pin_for_interrupt()), the gpio interrupt never gets called.
My question is, if it is possible to use same gpio pin for wiced_sleep_configure() & wiced_hal_gpio_register_pin_for_interrupt() ?
Thanks,
aniket
Show LessDear Infineon team,
We are going to get the SIG certification using the 89820.
But current SIG certification needs to use the TCRL 2019-2.
We've got almost part of the evidence for the Stack QDID. But certification company request the evidence of below item.
GATT/CL/GAR/BV-06-C | Read Characteristic Descriptors - by client | B | GATT 3/19 | TCRL 2019-2 |
We've referenced the QDID #115853.
Could you let me know how to get the evidence of this item?
Regards,
Wayne
Show LessHello,
I've recently been experimenting with flashing firmware to a CYBT-413055-02 with the "WsOtaUpgrade" tool built into
ModusToolbox2.2
I had no issues flashing a modified BLE_Beacon example to a brand new CYBT-413055-02 evaluation board over the air.
However, when attempting to flash the same firmware to a brand new CYBT-413055 module on a different PCB, the WsOtaUpgrade tool fails and states : "This device may not support OTA FW upgrade. Please select another device." This module is detected as "mtk_dut_413055" on a BLE scanner app.
Does anybody know what might be preventing me from flashing new CYBT-413055 modules OTA? Any insight would be greatly appreciated
Thank you
Show Less
Employee
Contributor
Contributor II
Contributor II
Employee
Employee
Honored Contributor
New Contributor
New Contributor II
New Contributor II