This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564: Audio Pops over I2S when CC2564 is master

Part Number: CC2564
Other Parts Discussed in Thread: WL1833,

I am hearing intermittent pops when data coming into the CC2564 over I2S is decoded on the far end. I’ve attached my configuration of the chip, and several waveforms that I captured using a scope with an I2S decoding module.  In the scope, the  yellow line is the BCLK, the blue line is the FSYNC, and the purple is the data. According to the scope captures, I am not seeing any discontinuities that would cause pops. It appears at times the data fluctuates between values of 0 and -1, but its not enough of a discontinuity to explain the pops. I’ve connected the CC2564 to a WL1833 and recorded the output from the WL1833. The attached wav file shows that in fact, we are getting some garbage data on the receiving side. Is there anything wrong with my configuration? And if not, how can I verify that the CC2564 is properly decoding the I2S data its getting so we can do a comparison between what we’re seeing on the scope? Roughly, the set up is as follows:
 
 
                   Scope                                                      Pops heard here
                      |                                                                    |
Host CPU -----> CC2564 ----> WL1833---> ALSA

I should note that audio for the most part sounds fine. If I play any voice or music over the I2S line, the audio sounds fine on the receiving end, there are just pops occasionally over it.

  • Hi,
    - can you pls share more test info ? What Host are you using for CC2564 , WL18xxMOD ?
    - can you pls share logs ?

    Saurabh
  • Sure. We are using and ARM based processor running Linux, and the WL18xx is hosted on a x86 CPU. However, I have heard the pops on a variety of receivers, including a Sena V 1.06 wireless headset. In order to test this setup, mag wires were added from the bit clock, I2S data, and frame sync between the host CPU and the CC2564, and I attached probes to those lines in order to get the scope shots. I have the logs from our process that manages configuring the chip, were there any other logs that you want specifically? I also added my configuration of the chip which I forgot to add to the original post. I have added my configuration and in the logs there is a different configuration where the bit clock rate is 3072 khz and the fsync duty cycle is set to use a 1 bit frame sync instead of 50% duty cycle, but both configurations produce the discontinuities.

    -- Logs begin at Tue 2018-10-02 14:47:11 UTC, end at Mon 2018-10-22 15:50:39 UTC. --
    Oct 22 15:03:14 garmin-sta1295-lawrence-mksa systemd[1]: Starting Garmin Bluetooth Gateway Manager...
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [] BGDB_Register(196): BGDB_Register
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [] BLUEGO_Init(384): >> BLUEGO_Init( ... )
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [] bgmgr_ChangeState(13681): BGMGR changing state from BGMGR_STATE_IDLE to BGMGR_STATE_INIT_CORE
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [] BGOSAL_OSPortInit(401): BGOSAL.startTime (unsigned) = 23024
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [] bgosal_ThreadTask(1103): bgosal_ThreadTask(): Task OSALTimer about to be executed.
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: Receive command
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: Receive command
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [370]       bgradio_ti.c (225)  |E|: Codec is configured successfully
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [379]       bgradio_ti.c (226)  |E|: CLOCK_RATE 3072
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [380]       bgradio_ti.c (227)  |E|: CLOCK_DIR 0
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [380]       bgradio_ti.c (228)  |E|: FSYNC_FREQ 8000
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [380]       bgradio_ti.c (229)  |E|: FSYNC_DUTY_CYCLE 1
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [380]       bgradio_ti.c (230)  |E|: FSYNC_EDGE 1
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [386]       bgradio_ti.c (231)  |E|: FSYNC_POLARITY 1
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [386]       bgradio_ti.c (232)  |E|: FSYNC_DIR 0
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [387]       bgradio_ti.c (234)  |E|: CH1 OUT SIZE 16 OFFSET 1 EDGE 1
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [387]       bgradio_ti.c (236)  |E|: CH1 IN SIZE 16 OFFSET 1 EDGE 0
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [387]       bgradio_ti.c (238)  |E|: CH2 OUT SIZE 16 OFFSET 17 EDGE 1
    Oct 22 15:03:15 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [387]       bgradio_ti.c (240)  |E|: CH2 IN SIZE 16 OFFSET 17 EDGE 0
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7027) |W|: BLUEGO_EVENT_SERVICE_UPDATED, but Service is null, or state != CONNECTED
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7029) |W|: service: BLUEGO_SERVICE_CALL_AG, fid: 65535
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7027) |W|: BLUEGO_EVENT_SERVICE_UPDATED, but Service is null, or state != CONNECTED
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7029) |W|: service: BLUEGO_SERVICE_CALL_AG, fid: 65535
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7027) |W|: BLUEGO_EVENT_SERVICE_UPDATED, but Service is null, or state != CONNECTED
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7029) |W|: service: BLUEGO_SERVICE_CALL_AG, fid: 65535
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7027) |W|: BLUEGO_EVENT_SERVICE_UPDATED, but Service is null, or state != CONNECTED
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7029) |W|: service: BLUEGO_SERVICE_CALL_AG, fid: 65535
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7027) |W|: BLUEGO_EVENT_SERVICE_UPDATED, but Service is null, or state != CONNECTED
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1303]      bgmgr.c      (7029) |W|: service: BLUEGO_SERVICE_CALL_AG, fid: 65535
    Oct 22 15:03:16 garmin-sta1295-lawrence-mksa systemd[1]: Started Garmin Bluetooth Gateway Manager.
    Oct 22 15:03:20 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [5157]      bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (22 bytes): AT+CSRSF=0,0,0,1,0,0,0
    Oct 22 15:03:20 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [5286]      avrcpsdp.c   (956)  |E|: SDP_ParseAttributes - Failure!
    Oct 22 15:03:20 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [5286]      avrcpsdp.c   (1046) |E|: could not parse SDP response
    Oct 22 15:03:20 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [5327]      bgpcm_avaal. (1309) |W|: Calling audio properties in a wrong state: 1
    Oct 22 15:03:20 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [5348]      l2cap_e.c    (4759) |E|: L2E_SetEnhancedoptions: unable to reserve TX blocks
    Oct 22 15:04:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [99189]     bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:06:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [219137]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:08:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [339139]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:10:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [459145]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:12:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [579147]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:14:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [699152]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:16:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [819139]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:18:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [939145]    bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:20:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1059134]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:22:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1179132]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:24:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1299131]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:26:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1419136]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:28:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1539157]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:30:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1659147]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:32:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1779132]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:34:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [1899140]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:36:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2019146]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:38:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2139136]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:40:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2259146]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:42:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2379140]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:44:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2499145]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:46:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2619144]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    Oct 22 15:48:54 garmin-sta1295-lawrence-mksa BtGatewayManager[473]: [2739153]   bgcallgwmgr. (1622) |W|:                 HFG_EVENT_AT_COMMAND_DATA -- AT (20 bytes): AT+IPHONEACCEV=1,1,9
    

    cc2564config.h

  • Hello Ben,

    Can you please add FW logs? This way we can see what is exactly is going on in the chip.
    Try to find overruns/underruns/ PLC being activated etc...

    BR,
    Chen Loewy
  • 1323.logs.zip

    This is the log that is going on before a SCO connection is started and continues when the SCO connection is actually started. I was hearing the pops while this logging was going on. Let me know if you need me to refine the logs in some way or something.

  • Hello Ben,

    I've went over the log and would like to ask you a few things.

    1. Can you please capture another FW log this time capturing both HCI Logger and LMP Viewer data?
    2. I can see the ESCO connection - i can see you still do page_scan - is there a reason for that? are you still trying to connect to other units?
    The more tasks running at the same time - the higher chance we might miss a packet and a tick sound will occur.

    Once i receive the log with more data i will go over it and try to find what is the reason for these ticks.

    BR,
    Chen Loewy
  • 3823.log.zip

    This log starts before the device is powered on and continues into when the pops start, and for a while after.

  • Hello Ben,

    Going over the logs the first thing i could see is that you are using SCO (HV3) and not ESCO - any reason for that?

    Beside that everything seems to be fine.

    I would suggest using 2-EV3 and trying this again.

    Can you please try that and update us on the results?

    Chen Loewy

  • The reason for using SCO and not eSCO is due to the handshake between the remote device. The remote device likely does not support eSCO.  However, I used a another SOC with a WL18xx on board for the far-end device, which I believe does support eSCO, and connected the CC2564 to that. I still heard the pops. Logs attached.connected_to_wl18xx.zip

  • Removed any calls to page_scan during a SCO connection, and that reduced the audible pops significantly. However, occasionally pops can still be heard, albeit much less. It seems like the root cause of this issue has not been found. Is there any way I can support further progress via firmware logs or something?
  • Hi Ben,


    Can you please capture logs now that you've removed the calls to page_scan.

    I will go over the logs and see if there is any way to improve this.

    BR,

    Chen
  • pops_still_page_scan_disabled.lgr.zipSorry for the late reply. I have attached the logs without the call to page scanning. We are calling BLUEGO_DiscoverableConnectable() in order to disable the scanning.

  • Hello Ben,

    Let's try the following please,

    can you send me the exact .bts/.txt init script you are using - i would like to add a few commands there and see how that impacts the performance.

    I'm trying to remove as many background processes.

    BR,

    Chen Loewy

  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/TI_5F00_CC2564x.7z

  • Hello Ben,

    Please try the following .bts file

    Please update once you get results.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/TI_5F00_CC2564x_5F00_27_5F00_11_5F00_18.7z

    Chen

  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/update_5F00_firmware.7zUpdated logging with new firmware: