Hi David,
Am 29.07.2020 um 16:42 schrieb David Shah dave@ds0.me:
Hi Nikolaus,
While debugging the glitching audio noise issue (usually during loud volume playback), it is starting to seem like it is of electrical origin. I can trigger it consistently by enabling the vibrate while sound is playing (regardless of volume).
I have tried and yes, I can trigger it sometimes through running the vibra through a second shell. Never did that before...
For me it happens only at higher volume levels. And sometimes it goes away if vibra stops. It always goes away if I stop aplay and restart. So something gets "reinitialized".
Interesting observation!
I also discovered that the TWL6040 has a test mode where it loops back downlink data to uplink.
I tested with this and the PDM data it was receiving was still correct, which pretty much eliminates a problem in the OMAP5 or between the OMAP5 and TWL.
Good to know.
This makes me think that high power consumption or electrical noise, due to loud volumes or the vibrate being turned on, is causing the TWL6040 to go haywire internally.
Hm. Yes. The speakers can draw up to ca. 1 Ampere peak current from the battery. This gives a significant noise and ripple at higher volume...
Comparing the Pyra schematics to the TWL6040 datasheet, it seems the 2.2uF capacitors on the HF amp and vibra power supplies are missing.
Indeed.
I have checked with the OMAP5 EVM and there, there are no capacitors as well.
Of course there are also no handsfree and speaker connector pins and the power supply is grounded :)
Next was to check the PandaBoard ES schematics. It has a common 4.7uF for both channels. And only vibra power is grounded.
So we probably did miss that when converting the OMAP5 EVM schematics into Pyra schematics and didn't compare with the PandaBoard and didn't look intensively into the twl6040 data sheets.
Are you relying on decoupling elsewhere being enough?
A look into the PCB data shows that the nearest decoupling is a little far away. Mainly it goes through the board-to-board connector on the main board. Room for a lot of resistance and inductance. And electrical problems.
Do you think this could be the cause of the problem (I appreciate if it is then not much to be done about it now other than find the best possible software workarounds.)
With this observation it is difficult to exclude this as the reason :)
If you see the loopback data being correct, I would suspect that something in the PWM system of the Class D driver gets out of sync. Maybe a clock looses some cycles or a (D)PLL becomes instable. It must be something indirect because the scratchy noise usually (not always!) persists until you end the aplay command and start a new one.
What I have seen is that there is room for an optional LED on the backside of the CPU board directly connected to these pins. It was left there from initial hardware debugging. It should be not too difficult to try to add a 4.7uF or 10uF capacitor there to test the result.
I am not sure if that would be a good mass production solution, because it sticks to the battery bay plastics and/or the heat shield and slows down the production process and/or must be hand-soldered.
But there would be room and easy access on component side of the LC15 processor board to add such capacitor(s) by modified copper trace layout. So it could be something for the next mass production run (unless ED has already ordered thousands of PCBs).
Thanks for being such lucky to be the first observer of the relation between vibra and handsfree sound quality which seems to be the key to fix it.
Best
David <twl6040_decoupling.png>
Best regards, Nikolaus