Just a quick heads up


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.
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.
 
I wouldn't worry. The Pyra may have a thin coating, but most of us have learned to be quite thick skinned.

Just to derail this thread even further. For some reason this reminded me of a forum that I used to post on back in the early 2000s. It used to get raided by another forum that was made up of banned members of the forum I was part of, we used to raid them back of course. There were the usual flamewars and arguments about random stuff as you'd expect.
One incident that stands out, is one bloke making the mistake of posting about how when he was a kid some other kids tied him to a tree and left him there. Cue the members of the other forum mockingly dubbing it the "Tree of Woe" and posting hand drawn pictures of a kid tied to a tree.
I ended up getting banned from the forum I posted on by one of the moderators due to lurking (so the message said). My guess as to the actual reason I was banned was due to me constantly making fun of the British National Party, and also due to the aforementioned moderator being a member of the British National Party.
So long story short, that's how my skin ended up getting thicker, shinier, and scratch resistant.

Edit: Just remembered, there was a member of the forum that I posted on who got banned due to trying to pick up underage girls.
 
Last edited:
Why do you think this will be stable over temperature and IC process variations?
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.
Usually one would want multi-nanosecond margins to protect against these variations.
Sure. We know that it depends on IC process variations since different units are not equally hit by the problem.
If you can sponsor a PCB redesign and a new production run to replace the already built boards or have a good idea how to retrofit it, it can be changed (e.g. add the inverter chip) to bigger margins to be always safe.
Ideally we would ask TI so solve this twl6040 erratum on the chip (they have too much delay when sampling data from the interface and putting it into some FIFO which uses another clock). Then we could solve the root problem for ca. 3,00€ (that is what the twl6040 costs)... But I doubt they will do it just for us.
 
Thanks for the update, ED.

Your baby grew up. I come to the conclusion the Pyra is already a teenager:

- She is concerned in how to shake her body while the music plays.
- Wants to look great in the photos that will be shared with friends, they're gonna love her story.
- Got beautiful new attire and wants to be sure it fits perfectly even if it needs some small arrangement (where's the iron again?).
- Needs to make sure her nail polish looks just right before going out and meeting new friends.

and naturally keeps shouting "I'll be ready in a minute!" to those impatiently waiting for her downstairs.
 
Last edited:
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.
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).
 
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.

The proven solution for that is an inverter - which does nothing else than inverting the impulses form the clock. Shifting the clock would have the same result, as the clock signal is continuos.
What we did by removing the resistor was basically shifting the clock. So yes, basically, it IS very similar to inverting the impulse, and while the clock signal might not be shifted exactly how much it should be, a clock signal also has a bit of a tolerance.

So if it works with multiple boards which I've tested and the original issue is the same on all of them, it's very likely the fix should also behave the same for all of them.
 
Yes, inverting and delay to a clock signal can have very similar effects. Chips and things that respond to a clock signal generally actually trigger on the rising or falling edge of the signal, not the actual voltage levels themselves. If you invert it the rising signal becomes a falling signal, and the falling edge becomes a rising edge (the signal forms an edge in both of these instances), whereas if you delay a signal both signals come later in time. But if the chip is looking at the rising edge, swapping the signal will put that signal where the falling edge would normally come, a millisecond or two later perhaps. Delaying the signal by a small fraction of a second will have the same effect, but if it's triggering on the falling edge, that will actually come before the rising edge when inverting but significantly later if you delay.

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.
 
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.
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...
 
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.
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.
 
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.

Did you made measurements with a scope yet? The shift of the edges should be measurable. If not, why not use a digital IC like the TXB0106. You should have them laying around. Use its propagation delay to test if this is realy the problem.
 
Measuring these kind of signals can be troublesome; the leads you use will have some capacitance in them, and depending on where you clip the ground pin to, you can pick up lots of signals there from RF via loop inductance. That extra 2mm of trace could be picking up RF noise from the vibrational motor, but I'd be slightly sceptical.
 
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.
 
Last edited:
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.

Aaaand... that software fix is being applied by removing a resistor?

This is a known hardware issue. It's in TI's official errata of the TWL. They even explain what they did wrong in the design but never updated it but gave a workaround.
So... you want to tell TI they don't know what they're designing but it's a software error instead...?
 
Yes, I'm not a big proponent of rumble features myself. The only occasions I can remember that they've been actually useful to me is when they indicate a hidden feature of a room you're in, which could be equally signified by the playback of a small tinkly sample. But they do seem to be a feature of modern controllers, so it makes sense to implement it, and as I say some games indicate secrets using it.
 
Last edited:
Back
Top