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
Am 01.08.2020 um 17:44 schrieb David Shah dave@ds0.me:
On Sat, 2020-08-01 at 14:02 +0200, H. Nikolaus Schaller wrote:
Am 01.08.2020 um 13:57 schrieb David Shah dave@ds0.me:
I notice that on the connector, the reference clock is next to the vibra signals, which would explain the coupling between them.
It is definitively worth to try. Unfortunatley I currently can't do such hardware work... Just information based...
I think given how close it is to all the other parts (particularly the connectors which are easy to melt) it is probably beyond my SMD skills too. EvilDragon, willing to give this a try?
So removing the resistor is definitely worth a try for that reason alone (not so sure this explains the interference from the speakers at high volume.) I think the real problem is just that the OMAP5 is exceptionally sensitive to noise on this signal.
I know of a similar strange hyper-sensitivity. If you touch a pin of the reset button on the OMAP5 uevm with the tip of the oscilloscope this will trigger a reset. To avoid such a problem we have added C2203.
Interesting, I wonder if it is something about the OMAP5 input buffers. Adding capacitors to clock lines is unfortunately a bit more dubious, but it might be worth experimentation on the uEVM with very low values (say <5pF should be OK).
Best
David
Best
David
On Sat, 2020-08-01 at 13:46 +0200, H. Nikolaus Schaller wrote:
Hi David,
Am 01.08.2020 um 12:51 schrieb David Shah dave@ds0.me:
Hi Nikolaus,
One last PCB question. Is R2102 populated on production boards, if so,
yes, it is. To (optionally) provide a SYSCLK to the main board. I think it is remaining when we tried to have the audio DAC of the Pandora on the Mainboard.
how long is the trace from R2102 to the connector? If it is non-trivial then removing R2102 could reduce the noise picked up by the clock.
Indeed. It is at least worth trying.
Here are some pictures.
This shows ABE-CLKS going from the omap5 to the twl6040 and then to R2102. This is ca. 50mm + 15mm
Here is the FREF-CLK1 ca. 50mm to R2101 and ca. 45mm to P2101
And finally FREF-ABE-CLK R2101/02 to P2102:
This is unconnected on the Mainboard.
So removing R2102 may remove ca. 5mm which isn't much.
Best regards, Nikolaus
Best David
On Fri, 2020-07-31 at 21:12 +0100, David Shah wrote:
On Fri, 2020-07-31 at 20:05 +0200, Michael Mrozek wrote: > Am Freitag, den 31.07.2020, 19:48 +0200 schrieb H. Nikolaus > Schaller: > > Just FYI: > As daveshah can now reproduce the issue on the uEVM, we're trying > the original > SDDK from TI. With old kernel, fully working AESS, etc.
Tested this now and it still glitches when I glitch the clock. Of course, this doesn't necessarily replicate whatever is going on in the Pyra. And the glitching is slightly different, same volume but slightly more "white" and with slightly more of the original of the original stream still coming through - so I guess either the old config or the AESS does change something.
> If we can glitch it there as well, then we could still try to add > the inverter - > but adding the inverter to the 500 produced CPU boards would't be > possible, I > guess. >
No, not if you want to retain your sanity :) But easy enough for me to buy an inverter and solder it to the uEVM just for closure on the issue if nothing else.
> If it's not possible to glitch it with TIs older OS, it's likely we > can somehow > fix it. > >> What could be interesting is to compare the sound/soc/ti/omap- >> mcpdm.c driver >> as well as omap-abe-twl6040.c between v4.7 and v5.x. It is not >> even necessary >> to compare the letux versions since the old kernel does not have >> any private >> patches and we tested the newer one without letux (aess) patches. >> >> It is a little more tricky to do that diff because the files have >> been >> moved to new locations. >> >>> Am 31.07.2020 um 19:29 schrieb H. Nikolaus Schaller < >>> hns@goldelico.com>: >>> >>> The kernel tree is here: >>> >>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-...
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel