BT-MSPAUDSOURCE-RD: Good reference design for BT audio Source device?

Hi Kevyk,

Please look into the A3DPDemo_SRC in the CC2564CMSP432BTBLESW. The user's guide for this SDK also includes details regarding supported HW EVMs.

Best regards,

Vihang

Thanks Vihang. That's a completely different hardware and software solution than the BT-MSPAUDSOURCE-RD. Right?

Is the BT-MSPAUDSOURCE-RD still a viable reference design for starting a new BT audio source device?

Thanks!

Kevin

Hi Vihang,

I moved to the CC2564C TI Dual-Mode Bluetooth® Stack at ti.com/lit/ug/swru497/swru497.pdf that you recommended but have a problem with audio not being sent. I made all the modifications asked on pages 5-7 and am able to connect to a device (Bose headphones in this case) and I can apparently open a Remote Stream but I never hear the audio. I looked at the timing signals for the I2S signals (AUD_CLK, etc) and do not see a clock being generated. I tried two different sets of boards as well. I double checked the cable and the voltages on all 4 boards. All seems OK.

Have you had anyone with success using the instructions at ti.com/lit/ug/swru497/swru497.pdf? Is there a configuration that needs to be changed in the CC2564CMSP432BTBLESW that is not specified?

I did implement the latest Service Pack update of a week ago.

Thanks,

Kevin

Hi Vihang,

I moved to the CC2564C TI Dual-Mode Bluetooth® Stack at ti.com/lit/ug/swru497/swru497.pdf that you recommended but have a problem with audio not being sent. I made all the modifications asked on pages 5-7 and am able to connect to a device (Bose headphones in this case) and I can apparently open a Remote Stream but I never hear the audio. I looked at the timing signals for the I2S signals (AUD_CLK, etc) and do not see a clock being generated. I tried two different sets of boards as well. I double checked the cable and the voltages on all 4 boards. All seems OK.

Have you had anyone with success using the instructions at ti.com/lit/ug/swru497/swru497.pdf? Is there a configuration that needs to be changed in the CC2564CMSP432BTBLESW that is not specified?

I did implement the latest Service Pack update of a week ago.

Thanks,

Kevin

Hi Kevin,

I put together a CC2564C + MSP432P401 setup to run the A3DPDemo_SRC demo, and have replicated and fixed the issue that you are seeing.

The problem is that although the instructions in SWRU497 mention putting the CC2564C PCM interface into slave mode, the codec is also still configured in slave mode when running the A3DPDemo_SRC demo. This means that the PCM interface is not clocked at all, as you discovered.

The fix to this is to simply set the CC2564C back into PCM master mode. This makes it generate the PCM clock and supply it to the codec. 

One last issue that you may run into is that by default, the Aud_in signal is pulled to ground through R11 on the CC256XCQFN-EM. This prevents the codec from providing PCM audio in. R11 needs to be removed if you have not done so yet.

Thus, for the CC256XCQFN-EM, the correct resistor settings are R11 = DNP, R18 = DNP, R19 = 10kOhm. Please modify your board to have the correct resistor config, and then try running the A3DPDemo_SRC demo again.

Regards,
Michael

Great! Thank you so much. But if there has been a bug in TI's reference design at ti.com/lit/ug/swru497/swru497.pdf all along, how can it be that I am the first to find it since that reference design is 3 years old? No one else has come up against this in 3 years?

How do I set the CC2564C back to PCM master mode as you suggest?

Since the clock signals will now be SOURCED from the CC2564C and not the audio CODEC on the CC3200AUDIOBOOST: R11 is a DNP so audio signal is not grounded, R19 is a 10K (or short to ground) so the clock signals travel in the proper direction, and R18 is a DNP. Right?

I also found a number of other more minor issues with the schematics being labeled incorrectly here and there and a minor bug in the stack with a #if that should be a #ifdef (search for __SUPPORT_AUDIO_CODEC__ in the HAL.C file).

Thanks.

Refer to e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/833473/3087066#3087066 for more details.

Works! Finally. 2 weeks spent (won't say wasted). Still surprised no one else found or reported this in 3 years. You might want to have TI update the docs and tweak the code... This IS a REFERENCE design after all.

Thanks for all the help!

Recently, I also have the same problem at the A3DPDemo_SRC of CC2564CMSP432BTBLESW 
(MSP-EXP432P401R+ BOOST-CCEMADAPTER + CC256XCQFN-EM + CC3200AUDBOOST)

I saw the user Guide(http://www.ti.com/lit/ug/swru497a/swru497a.pdf)  Table 1. at page 5.  and your suggestion removing the R11 resistor then  the A3DPDemo_SRC  enable to transmit audio.

I just replay to someone to know this suggestion is working.


I take volt-ohm-milliammeter to measure the R11 resistor the value is zero ohm before removing R11 resistor. Why not the product CC256XCQFN-EM original status of R11 is uninstalling  the same as R18?
The audio Demo ( A3DP Demo_SNK, A3DP Demo_SRC, HFP Demo_AG, HFP Demo_HF, and HSP Demo ) from user Guide just only A3DP Demo_SNK is required R11 is zero ohm or uninstalling status, but others is uninstalling status. The resistor is very small and I think installing maybe easier than uninstalling.

Yes Jussie, TI's finally fixed the reference design at ti.com/lit/ug/swru497a/swru497a.pdf. The documentation is now CORRECT (September 2019).

R11 needs to be removed. R18 needs to be removed. R19 can be shorted together or place a 10k across the pins - either way works. This sets the level shifters on the CC256x board to transmit the two I2S clocks to the CC3200 board. The audio signal is sent from the CC3200 board to the CC256x.

Then install the software to make these boards behave as a BT Audio Source device.

Good luck - It took me a week to find this error in their documentation!