TAS5828M: I2S: Clock Detection Fault

Hello Edwin,

Can you provide your schematic. Have you setup a fault triggered waveform capture to observe any other signals when the clock fault is observed? Is there any other faults triggered?

best regards,
Luis

Hi,

Here is the schematic, nothing special, quite your suggestions in the datasheet ... The three GPIO-Pins are not used, because everything is running over I2C.

* The power output signals: Nothing special, the are just going to high-Z.
* Register 0x71, bit 2, CLK_FAULT_IR0 is the only one bit, everything else is 0 ... registers 0x70 und 0x72 are 0. Hence, no other faults.
* This occurs on one print, at higher load when the IC gets warm. Without load or at lower power voltage, there is no problem. Hence, I'm sure that the I2S signals are correct.

Is it possible, that the clock fault detection might detect an error even if there is none?

Best regards,
Edwin

Hello Edwin,

Can you capture your I2S bus during this high temperature condition where you are driving this high output power. Also can you check the Warning bits to see if the Over Temperature warning is being flagged?

best regards,

Luis

Hi,

The software checks the flags using I2C. The registers 0x70, 0x71 and 0x72 are read 10 times per second. The Warning register 0x73 too.

The clock fault bit is the only one bit that get the value 1. Other values remain 0. Interesting ...

Best regards,
Edwin

Hi Edwin.

I have some questions need to confirm with you:

1. How many prototypes have such problems? If so, could you help to do a test, A to B and B to A test? Swap the chips on the two boards to see if the same situation occurs.

2. Could you write 0x40 to register 0x29 to observe if the problem still exist?

3. Could you also write 0x20 to register 0x29 to observe if the problem still exist?

4. Could you also write 0x08 to register 0x29 to observe if the problem still exist?

1 is to judge if this a problem with individual chips.

2,3,4 are to judge this is caused by internal OSC clock's problem.

BR.

Wei Qiu.

Hi,

I've got five prototypes and one is showing this behavior. Changing the physical IC  is something I can do, but I do not want to (rather difficult, a lot of other parts next to the IC).

And: I will check the exact fault source today ... and write the results in the next message ...

Best regards,
Edwin

... everything remains quite interesting. I tried different values for the clock fault detection and found out which error occurs:

* Writing register 0x29 to 0x10 is a solution/workaround: Hence it's a "FS Error". Frame Sync error? Interesting ...
* I cannot imagine that the uC/DSP has different McBSP/I2S output signals when the power amp gets warmer.
* As I wrote before: The I2S signals are exactly the way the datasheet tells.

* But: There is one special thing. The sample rate is not a common value. Its (mathematical) value is 40064.10256: 200M/78/64 ... ok, the exact value depends on the dsp clock crystal tolerance. But I cannot imagine that this might be of interest. (Register 0x28 is set to 0x00 ... auto detection)

Is there a rational explanation for this behavior?

Thanks and best regards,
Edwin

Hi Edwin.

According to your description, it seems that this issue is caused by lower FS frequency. The tolerance of FS is around 10%, the down limit is around 40.03kHz. Considering the internal OSC frequency will have some offset due to high temp,  40064.10256Hz has none margin.

We strongly to increase the FS frequency and have another try.

BR.

Wei Qiu.

Hi,

Thanks, that's interesting. First some additional information to my application:
* I use the TAS5828M ase power dac for audio signals.
* I am not interested in the internal dsp functions ... just the overcurrent/overtemperature stuff is fine.
* There are complex mathematical calculations running in the dsp/uC. Hence a higher sampling rate would do no good.

Do I understand the situation correctly?
* The TAS5828M does some sample rate (=frame sync) monoitoring by comparing the input signals with an internal reference oscillator.
* The threshold window is approximately +/- 10% ... the reference oscillator will change its reference depending on the IC temperature ... of course.
* Hence, the 40kHz might be ok, but might cause the detection of a sample rate error.

So, there are two possible solutions;
1. Changing the sample rate to the recommended values (32k2 44k, 48k, ...). Not useful because of SW complexity.
2. Turning of the sample rate monitoring my setting the bit in register 0x29. This is the preferred solution, because it might get necessary to decrease the sampling rate to 38kHz or 36 kHz. And these values are no common values.

If I get rid of this problem by turning off the sample rate monitoring I would say: Problem solved! Is this ok?

Thanks and best regards,
Edwin

Hi Edwin.

Edwin Krasser said:

Do I understand the situation correctly?
* The TAS5828M does some sample rate (=frame sync) monoitoring by comparing the input signals with an internal reference oscillator.
* The threshold window is approximately +/- 10% ... the reference oscillator will change its reference depending on the IC temperature ... of course.
* Hence, the 40kHz might be ok, but might cause the detection of a sample rate error.

Yes, your understandings are right.

Edwin Krasser said:

So, there are two possible solutions;
1. Changing the sample rate to the recommended values (32k2 44k, 48k, ...). Not useful because of SW complexity.
2. Turning of the sample rate monitoring my setting the bit in register 0x29. This is the preferred solution, because it might get necessary to decrease the sampling rate to 38kHz or 36 kHz. And these values are no common values.

We more recommend using solution 1. Because large sampling rate deviations can cause problems with switching frequency or audio performance.

BR.

Wei Qiu.

Hi,

Thanks, now I have better understandings of thus stuff. Well, one final question:

Do you recommend to set FS to 44 kHz because it's the nearest frequency? Or should I use auto detection?

And: The sentences "Need set it manually If the input Fs is 44.1kHz/88.2kHz/176.4kHz." are e little bit strange ... does this mean that I need to set it to 44 kHz anyway?

Thanks and best regards,
Edwin

Hi Edwin.

Set the sample rate to 44.1kHz manually is better.

BR.

Wei Qiu.

Hi,

Thanks. I just wanted to implement everything. But it gets funny by now ...

I think I have to set the SIG_CH_CTRL register 0x28 (see photo of last message). Now I initialize it to 0x00 ... auto detection.

Which value is correct? FSMODE is just one bit but I should write  b1000=0x8 into it ... that's difficult. So I think there is a mistake in the datasheet. Which value shall I write to register 0x28?
Shall I set it to 0x08 ... bit length auto detection and [FSMODE, 3x reserved]=b1000=0x08?

One more thing, I just tested the FS_MON register (register 0x37) ... its value is 0x09 ... sampling rate 48 kHz ... and there is no bit combination for 44.1 kHz in the table (Table 8-23).

Thank you very much and best regards,
Edwin

I just tried register 0x28=0x08 ... continuous clocking error, hence silence.

Best regards,
Edwin

Hi Edwin.

Sorry for the mistake in the datasheet, we will later modify this.

Bit0~bit3 is to set the FS,  set 44.1kHz is to write 0x08.

Auto detect can't detect 44.1kHz sample rate.

Edwin Krasser said:

I just tried register 0x28=0x08 ... continuous clocking error, hence silence.

40k sample is close to the down limit of 44.1kHz(+/- 10%). Could you try to increase the sample rate and have another try?

BR.

Wei Qiu.