A small capacitor on the signal would be very interesting to try, good idea!

David

-------- Original message --------
From: "H. Nikolaus Schaller" <hns@goldelico.com>
Date: 19/10/2020 15:10 (GMT+00:00)
To: dave <dave@ds0.me>
Cc: Michael Mrozek <EvilDragon@openpandora.org>, kernel@pyra-handheld.com
Subject: Re: TWL6040 decoupling

Hi David,

> Am 19.10.2020 um 15:51 schrieb dave <dave@ds0.me>:
>
> Hi Nikolaus,
>
> Good thinking, but I remember trying that in the last set of tests and no dice. I think the problem is noise on the clock from TWL to OMAP setting the PDM modulator out of kilter until it is reset, rather than just a phase issue.

Ok, yes there is a good argument for this theory: the problem starts when the vibramotor runs. And it does not end after it stops.
This indicates that some PDMCLK/LB bit is completely lost and not only delayed (which would sample wrong data bits but with correct clock and speed).

And if we just have 10ns the wires are RF wires and a T-connection and an open end can reflect and modify the clock pulses significantly enough so that the omap and the twl6040 do no longer agree that there was a clock impulse...

On the other hand it still could be the data sampling issue if the delays depend on power supply voltage. If the vibra or handsfree speaker is activated it increases power demand and voltage goes down. This may increase/decrease the clock delay and bit errors start. As soon as bit errors occur we have noise which keeps power demand high and therefore does not stop - unless we stop the music completely. Maybe it would then stop in a pause with 0x0000 data but as soon as some 0x0001 is read as 0x8000 in the next word the problem remains activated.

In any case we could try a small damping capacitor on PDMCLK (ABE-CLKS). It should block short spikes and add some more clock delay.
But it is very difficult to apply since there is only one PCB location where we can access PDMCLK/ABE-CLKS on the PCB surface.
Not a simple workaround that can be easily applied in factory.

BR and thanks,
Nikolaus


>
> Best
>
> David
>
> -------- Original message --------
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: 19/10/2020 14:41 (GMT+00:00)
> To: David Shah <dave@ds0.me>
> Cc: Michael Mrozek <EvilDragon@openpandora.org>, kernel@pyra-handheld.com
> Subject: Re: TWL6040 decoupling
>
> Hi all,
> picking up this discussion on Michael's suggestion, I have looked again into the details of the problem.
>
> I noticed that there is the PDMCLK-Output which makes trouble depending on chip internal, external (wire length) and OMAP delays.
>
> This would verify that we really have the problem described as OMAP5 erratum i800 resp. twl6040 erratum 6 "PDM Downlink Data Corrupted".
>
> Now I found reference that the PDMCLK is either derived from MCLK (which is our 19.2 MHz master clock) or the 32kHz low-power clock.
> In any case the MCLK is 19.2 MHz and the PDMCLK is usually 19.2 MHz.
>
> If I look at the timing figure of the twl6040 erratum 8 there are less than 26ns available for all the delays of the buffers plus the pdm-clk.
> I wasn't aware that both directions count (twl -> OMAP and back) so the real margin is probably less than 10ns for the wiring on the PCB.
> This is roughly equivalent to 3cm distance between twl6040 and omap.
>
> Another finding is that if the PDMCLK is derived from 32kHz it can also be 17.64 MHz which would give some additional ns margin for
> the signal delays and avoid the twl erratum.
>
> Is it possible to switch the twl6040 to run from 32kHz and use PDMCLK 17.64 MHz to check if it makes a difference?
>
> BR and thanks,
> Nikolaus
>
>