CC8520: No data transmission with PurePath CC8520 based project

Hello Roland,

You may try attaching the project file again as it did not succeed the first time.  Your customer may consider submitting their HW design to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS since it would seem that they are having reception issues even with a PA device.  They can also refer to the TIDA-00232.  You can use the PUREPATH-WL-CMD for production test and EHIF command/monitoring to help verify your solution.

Regards,
Ryan

Dear Ryan,

thanks for your feedback, we have asked the question to Roland. 

For the reach problem, we think we know what the problem is and we will fix it in a redesign of the PCB. However, it seems to us that in the audio transmission we have an additional problem, which we cannot find. Within the (currently limited) reach the receiver and transmitter can connect and go to Active state, observed by constant LED on status. The ADC is sending audio via I2S to the transmitting CC8520, but the receiving CC8520 does not output anything on its I2S data line (I2S clocks are output fine). So my first question would be: Is our assumption correct, that in Active state the audio data should be transmitted? What could be possible reasons why the audio is not transmitted in active state? Can we somehow find out if the audio is muted already in the transmitting or the receiving CC8520?

Hi Markus,

You can check section 2.1.5 (Serial Audio Interface) and 3.5.1 (Audio Streaming Control) of the CC85XX Family User Guide for I2S operation.  This document will also help with mute behavior information and how to modify this status accordingly.  All devices are muted upon power-up and must be unmuted in order for volume settings to be effective.

Regards,
Ryan

Hi Ryan,

thanks for the hint, we indeed overlooked that all devices are muted at startup. We added a button event to unmute all devices in the master IO mapping (autonomous operation), however, it did not change anything. When clicking the button to unmute, the receiver still outputs all zeros at the I2S data line. What else could be the reason?

Best regards,

Markus

Hi Markus,

I recommend using the PS_AUDIO_STATS to determine the mute behavior of your device.  Please also note the following: In case the required minimum data throughput to allow audio streaming is not possible, the audio output on an audio consumer is muted on all channels on node(s) failing to receive. Hysteresis is applied to avoid situations where audio is streamed only intermittently.  The mute issue may be resolved if the connection between the nodes is improved.

Regards,
Ryan

Hi Ryan,

thanks, we also thought that the reach issue might be blocking audio transmission even when the two sides can go in "active" mode. We are currently running a redesign of our boards to fix it and will check again with the new boards. Please keep this thread open, we will let you know as soon as we have the new PCBs.

Best regards,

Markus

So, reach is improved, but we still cannot get the receiver to unmute. Attaching screenshots from master and slave for ps_audio_stats() and ps_rf_stats(). So it looks like the master gets audio correctly from the ADC and transmits it to the slave. The slave receives it pretty well (failed packet receptions are pretty low), but all samples are muted. Whatever we do, we cannot get the audio unmuted: Mute button local or remote, or VC_SET_VOLUME() remote or local, nothing has any effect on the muting.

2021-04-09 RF Audio Statistics.pdf

Add. info: When switching off close-by WiFis, I can even get the RF packet errors down to zero. Nevertheless, audio does not get unmuted. 

Markus,

Can you please try sharing your PPW Configurator device configurations? The 2 device configurations you shared in the previous post have errors when viewing them, so I want to make sure I can see all your PPW Configurator settings.

Specifically, I would like to double check the Audio Interface and Audio Streaming settings for both the input master and output slave.

Thanks,

Daniel

Sure, attached is the last test version we tried. Note, that the master is supposed to transmit 2 channels whereas each slave is supposed to pick only 1 channel depending on IO settings.

Thanks, Markus.

I still don't see your Audio Interface configuration. Are you using a custom external audio device? If so, can you please share the custom .ppwadd file or settings? Or do you have it set to generic digital audio device?

A couple of debugging suggestions: 

1. Try using 1 channel on your source device, and 1 channel on your output device
2. Try replacing the receiver with a CC85xx EVM
3. Try replacing the master with a CC85xx EVM

Regards,

Daniel

Hi Daniel,

the master is using a PCM1808 ADC, which is fully hardware configured, so the .ppwadd model we made is more or less a dummy. The slave is using a TAS5805, which is I2C controlled. I am attaching both models here. 

I think the interface between the PCM1808 and the master CC8520 is working fine, as we can observe the peak and mean values of the audio signal in the ps_audio_stats(). The model of the TAS5805 might still have an issue, but we should at least see the audio signal coming out of the I2S of the slave CC8520. Fixing the TAS5805 model should be easy then. 

We will try the 1-channel transmitter tomorrow, but I am not sure how this should help. The transmitter should be able to transmit 2 channels while the receiver picks 1 channel. 

Regards,

Markus

Markus,

The suggestion is just to reduce complexity and help narrow in on the problem. That's why I also suggested replacing the master, then the slave, in your system with the CC85xxDK and the default image. This should help us narrow down where the issue is.

It does seem likely that the issue is with the TAS5805 model.

Regards,

Daniel

I would understand that the audio output of the receiver´s TAS5805 might be mute if the TAS5805 model is not correct and the volume control of the the TAS5805 does not work properly. But why would the CC8520 refuse to output the audio on the I2S interface? We observe the I2S data line by oscilloscope and there is no audio at all transmitted from the CC8520 to the TAS5805.

What I can confirm is, that there seems to be some sort of check in the CC8520 for the I2C interface, because if we don´t assemble the TAS5805 on the PCB, the CC8520 does not even start up. So it seems that the CC8520 is checking the acknowledge bits of the TAS5805 on the I2C interface, which appears at the same time to confirm that the I2C communication with the TAS5805 works. 

Is there any other acknowledgement the CC8520 is expecting from the TAS5805 which might cause it to stay mute on the I2S interface?