Why do you think this will be stable over temperature and IC process variations? Usually one would want multi-nanosecond margins to protect against these variations.It is even in the pico seconds range. There is a very small time slot where the clock is not allowed to change or otherwise the data bits going over a serial line are sampled wrongly disturbing the digital audio going to the amplifier and speaker. It may sound strange that removing an unused resistor is sufficient, but even this resistor is physically also a capacitor and an inductor as well as the wire connecting it. And in the pico-seconds range this may already make the difference. It is a world where digital signals meet analog signals.
All you had to do was follow the damn train, CJ !Mission passed, respect +1
I wouldn't worry. The Pyra may have a thin coating, but most of us have learned to be quite thick skinned.
Short answer: we do not know. ED is modifying some boards and then we will see if the cure for his test unit works there as well.Why do you think this will be stable over temperature and IC process variations?
Sure. We know that it depends on IC process variations since different units are not equally hit by the problem.Usually one would want multi-nanosecond margins to protect against these variations.
OMAP+TWL6040 use a protocol called McPDM but it is similar to SPI and I2S. Unfortunately we have not found any registers for inverting the clock out pin... If you are interested in the details, it is twl6040 erratum #8 "PDM Downlink Data Corrupted" in TI document SWCZ0007D from 2011 (it seems to be NDA only).I'm still a bit concerned about the audio issue. My high speed circuits had quite a bit of timing drift regarding temperature and did a automatic delay calibration on every startup. For me, this sounds like a SPI mode issue, just for I2S or whatever is being used. The newer chips I'm using have a config register for the IO Bank which allows for inverting some pins individually. I don't know the OMAPs IO config, but if it's possible, inverting the clock out pin could be a more robust fix I think.
The clock line is not a straight wire from OMAP5 to TWL6040 but has a stub to the board-to-board connector because originally it was intended to have a different audio circuit on the main board, also connected to this clock. But that is not used and the wire to the board-to-board connector ends at the connector. It goes through a 0 Ohm resistor (jumper) because there was an option to provide a different clock to the same pin of the board-to-board connector. Now, removing the resistor makes the wire ca. 2mm shorter and removes the capacity of the connector pins. This seems to be sufficient to move the clock edge seen by the TWL6040 by some picoseconds out of the critical window. Or it modifies the reflections by the open ended wire. Think of having a rope with a stone at the far end. If you remove the stone the rope moves much differently. We don't exactly know which reason is the right one because it is very delicate to measure such things with an oscilloscope (which has an input capacitance of usually 10 or 20pF and touching the wire with the tip changes the signals). So far the analysis and theory. Yes, adding a damping/smoothing capacitor (which introduces delay) would be better and better controllable, but it is much more complex to retrofit it compared to removing the resistor. This is a business decision...The only unexplained bit for me is how removing a resistor results in a delay to the clock line. A capacitor will effectively smooth out the clock, causing a kind of delay to the time a transistor inside the chip activates. Perhaps it used to be used as a kind of low pass filter using a resistor and a capacitor, and removing that resistor effectively disables that signal entirely, perhaps leaving the capacitor as a kind of smoothing capacitor (but on the clock signal). If there's any sense in that, I can't see how it would be significantly affected by a change in the ambient temperature.
Recently I have checked one of the early Pyra prototypes built ca. 3 or 4 years ago and initially everything was fine. No problems with audio. Like it was years ago where we assumed no problems with audio. Until I tried to run the vibra motor while music was playing. This was too much for this unit and had remained unnoticed for these years (or there had been a lot of opportunities to add some measure). I also found some very old test kernels (Linux v4.14) and they did show the same effects although the omap sound drivers were turned upside down in the meantime. Therefore we believe that it is the hardware erratum #8 mentioned before and not a software issue.Well, regarding audio: So far, all prototype units had the exact same problem with audio.
There were a few that have been more sensitive than others (stream crashing more likely), but ALL of them had a corrupted audio stream as soon as vibration had been enabled.
It's not rocket science, it's quantum physics.Yeah I remember diagnosing a PLL lock issue with an ASIC I was bringing up the Test program for, every time I went to put a scope to check on the issue the problem went away. It was a funny exercise of how observation can effect the results.
When the motor is running some edgeds of signals are no longer aligned properly. And then, removing a resistor fixes that? For me, this sounds like AC-Noise that in the end was a software issue. But i know, i was wrong back then.