A tiny bit more insight.
It also seems possible to stop the glitching by disabling the _up_link channels on the OMAP side, either by clearing PDM_UP[1-3]_EN or setting SW_UP_RST in MCPDM_CTRL.
This actually seems slightly more reliable than disabling the loopback clock input buffer. But I suspect disabling that input buffer also breaks the uplink path, I haven't tried yet.
Disabling the uplink by disabling the uplink data input buffer, on the other hand, does not fix the glitching, so the glitching is not some strange result of the uplink data stream itself. Instead there must be some strange cross-connection between the up and down link in the OMAP5 that gets messed up by electrical noise (???). All the more mysterious...
As a worst case scenario, a patch that fully disabled the uplink channels when not being used would already improve reliability a lot. The mechanical noise of the vibra would make the internal microphone useless anyway.
Best
David
On Thu, 2020-07-30 at 13:10 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 13:02 schrieb David Shah dave@ds0.me:
On Thu, 2020-07-30 at 12:37 +0200, H. Nikolaus Schaller wrote:
Yes, I can confirm the effect.
After doing devmem2 0x4A0029A0 w 0x0080118 sound output stops (but aplay continues to run without notice about buffer under/overflow or alike). After restarting aplay sound is better. And vibra influence is no longer noticeable. Restoring devmem2 0x4A0029A0 w 0x1080118 makes problem come back
even while aplay runs. But still it depends on volume. So high volume + 0x1080118 is unreliable.
Hm. Is there a clock polarity setting? Either in McPDM or the twl6040? If clock polarity would be wrong, then it may depend on power supply noise if the data line is sampled correctly and the previous bit value creeps in or some random bit is read.
As far as I know there isn't one; the errata does suggest adding an external inverter to work around a clock phase issue (but I don't think that's exactly the same problem as what we see here.)
Ok, that could be the missing inverter I had hoped that it can be software controlled... Adding one in hardware would be more difficult than the missing capacitor :(
There are also the OMAP IO drive strength and slew settings to play with though.
Indeed. If the drive strengh is higher the slew rate is higher and the risk of sampling the wrong value should go down. Let's hope it goes this way...
BR, Nikolaus
Am 30.07.2020 um 12:20 schrieb H. Nikolaus Schaller < hns@goldelico.com>:
Wow! Maybe you can ask Peter Ujfalusi as he has done a lot of previous work for twl audio.
I'll check all this as soon as I find time.
BR and thanks, Nikolaus
Am 30.07.2020 um 12:15 schrieb David Shah dave@ds0.me:
Well, I seem to have found a solution. It is totally and utterly inexplicable, but there you go.
The OMAP5 TRM says that the input buffer for MCPDM_LB_CLK - the clock going out from the OMAP5 to the TWL, that clocks the PDM stream and mirrors the TWL clock output - must be enabled; as the input signal is used internally for retiming purposes.
But using devmem2 to DISABLE this input buffer, against the TRM advice, seems to fix the stream desynchronisation issue!
# devmem2 0x4A0029A0 w 0x0080118
There is still a quiet a crackle when the vibra turns on or off, which really does seem like switching noise from the motor, but the stream is never actually corrupted and the crackle does not disrupt what is playing!
I'm done with OMAP stuff for today :) but I'll experiment more over the weekend. If you get a chance, I would be interested to see if this is reproducible on your unit, too.
I need to think a bit more about how this could actually look from a silicon point of view to see if there is a better fix. It is possible that disabling the input buffer means that the OMAP5 is using some internal clock instead that isn't disrupted by noise on the pad.
It could also be related to OAMP5 errata i800 / TWL errata 6, which involves relative clock phases. I had ruled that out because it would be odd for power supply noise to affect that; and it reads more like dropped/duplicated samples than total loss of stream.
Best
David
On Wed, 2020-07-29 at 18:32 +0100, David Shah wrote:
Hi Nikolaus,
Couple of thoughts below.
On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus Schaller wrote: > > Am 29.07.2020 um 18:58 schrieb H. Nikolaus Schaller < > > hns@goldelico.com>: > > > > > > > Am 29.07.2020 um 18:04 schrieb David Shah < > > > dave@ds0.me>: > > > > > > Hi all, > > > > > > I tried adding a 470nF 0402 capacitor in what I hope > > > was > > > the > > > right > > > place (see attached), > > > > yes, from a first glance it looks to be right! > > > > > and replacing the associated resistor with a > > > short. Sadly that made no difference, but maybe 470n > > > isn't high > > > enough > > > (I also have 4.7u 0805 but I suspect that might be > > > too > > > tall. > > > > Hm. I hope I find some minutes to open my sample and > > try > > the > > same. > > Then we know. > > Here is a full picture where I tried tp mimic the > colours: >
Yes, that matches what I did.
> Maybe the copper trace between the C and the R is too > small. > So a > wire directly > across all three solder pads could be better. Or > scratching > off the > solder mask from > the ground plane around and soldering the capacitor > directly > to > GND. >
In my second attempt with 4.7u, I did effectively end up with one solder blob all the way across that should be pretty low impedance.
> If I find time (which is unfortunately unlikely) I could > add > two > wires to the pads of the > capacitor and get them outside the Pyra to be able to > measure > the > voltage with the oscilloscope. > > Some thoughts about the software side: I remember that > Peter > Ujfalusi > long time ago mentioned > different clocks. Maybe the 32kHz clock or the McPDM > clock > which > could be used as a > reference. And there was a kernel version where sound > became > a > little > better (but I wouldn't > bet for it). So there may still be another effect in > software. > Maybe > in addition so that > what we observe is the sum of several effects. >
Interesting, the clocking definitely isn't quite right in the latest as high power mode also used to work on 4.19 but doesn't seem to any more.
> One question about the loopback: does it show if the PCM > data > is > coming in the right > and stable timing? E.g. speed may fluctuate but still > provide > perfect > data mirroring. > Nevertheless, fluctuating speed may become audible. >
This is true, there is some possibility for "common mode failure" that would symmetrically affect both directions.
> But it is difficult to see how this would be influenced > by > the > Vibra. > Well, the Vibra > is also controlled through some PCM channel because the > motor > can > "play" the bass sound... > The Vibra seems to be set to "Input FF" mode by default AIUI it is controlled by I2C not the PDM stream when using vibra.py. But you can set it to PDM mode in alsamixer which seems to turn it always on (presumably a 1 is sent in the PDM stream for that channel by default?) noise that always goes away as soon as you turn it off again rather than glitching the stream.
It also seems to differ significantly less depending on the volume setting - it isn't directly scaled by volume in the same way as Vibra Right glitching is; as if it is affecting something later in the signal path.
Strange that an unconnected channel also makes a difference, but the H- bridge is still presumably still switching and any H-bridge does produce some shoot-through noise.
I am wondering now if some config issue is making the TWL much more sensitive than it should be for some reason.
Best
David
> > > I'm still proud to own the first modded Pyra, even > > > though > > > it > > > didn't > > > work :D > > > > ++ > > > > BR, Nikolaus > > > > > Best > > > > > > David > > > > > > On Wed, 2020-07-29 at 17:37 +0200, Michael Mrozek > > > wrote: > > > > Am Mittwoch, den 29.07.2020, 17:25 +0200 schrieb H. > > > > Nikolaus > > > > Schaller: > > > > > > > > Hi, > > > > > > > > > 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. > > > > > > > > Oh, that's good news! > > > > Can you let me know where to solder them so I'll > > > > try > > > > that > > > > here? > > > > > > > > > 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. > > > > > > > > Well, we tested various materials between the CPU > > > > board > > > > and > > > > the > > > > plastics - but > > > > the best solution is to put NOTHING in between. > > > > > > > > If we put a metal sheet in there, the heat goes > > > > into > > > > the > > > > metal > > > > and > > > > heats the > > > > battery - whereas almost nothing moves into the > > > > heatsink > > > > (where > > > > it > > > > should). > > > > > > > > So there's a gap of 0.4mm between the CPU board and > > > > the > > > > backside, and > > > > as the > > > > keymat acts a bit like a cushion as well, I guess a > > > > small > > > > part > > > > like a > > > > capacitor > > > > could even use up to 0.6 to 0.7mm. > > > > > > > > So there should be enough space to put a small > > > > capacitor in > > > > there. > > > > > > > > > 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). > > > > > > > > We have 500 already-produced PCBs - so I guess we'd > > > > need to > > > > fix > > > > these > > > > manually. > > > > But hey, MWeston had to replace 500 capacitors on > > > > the > > > > Pandora > > > > PCBs > > > > manually as > > > > well. > > > > > > > > Only bigger downside would be that we have another > > > > setup > > > > costs > > > > for > > > > the next CPU > > > > boards... that's around 5000 EUR alltogether :/ > > > > > > > > > > > <photo_2020-07-29_17-03-18.jpg> > > > > _______________________________________________ > > Kernel mailing list > > Kernel@pyra-handheld.com > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 30.07.2020 um 20:29 schrieb David Shah dave@ds0.me:
A tiny bit more insight.
It also seems possible to stop the glitching by disabling the _up_link channels on the OMAP side, either by clearing PDM_UP[1-3]_EN or setting SW_UP_RST in MCPDM_CTRL.
This actually seems slightly more reliable than disabling the loopback clock input buffer. But I suspect disabling that input buffer also breaks the uplink path, I haven't tried yet.
Disabling the uplink by disabling the uplink data input buffer, on the other hand, does not fix the glitching, so the glitching is not some strange result of the uplink data stream itself. Instead there must be some strange cross-connection between the up and down link in the OMAP5 that gets messed up by electrical noise (???). All the more mysterious...
That is certainly something to discuss with TI people (Peter Ujfalusi is still active - sent a mail a week ago about "omap-mcbsp 49022000.mcbsp: TX Buffer Overflow!").
As a worst case scenario, a patch that fully disabled the uplink channels when not being used would already improve reliability a lot. The mechanical noise of the vibra would make the internal microphone useless anyway.
Not necessarily since the mic has a sound guide and small hole on the left side of the keyboard. So it may be possible to hear the rumble but it would not make the recorded sound useless. It may even be possible to do noise cancelling for the vibra activities through aess (yes I know it is a dream)...
Best regards, Nikolaus
Best
David
On Thu, 2020-07-30 at 13:10 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 13:02 schrieb David Shah dave@ds0.me:
On Thu, 2020-07-30 at 12:37 +0200, H. Nikolaus Schaller wrote:
Yes, I can confirm the effect.
After doing devmem2 0x4A0029A0 w 0x0080118 sound output stops (but aplay continues to run without notice about buffer under/overflow or alike). After restarting aplay sound is better. And vibra influence is no longer noticeable. Restoring devmem2 0x4A0029A0 w 0x1080118 makes problem come back
even while aplay runs. But still it depends on volume. So high volume + 0x1080118 is unreliable.
Hm. Is there a clock polarity setting? Either in McPDM or the twl6040? If clock polarity would be wrong, then it may depend on power supply noise if the data line is sampled correctly and the previous bit value creeps in or some random bit is read.
As far as I know there isn't one; the errata does suggest adding an external inverter to work around a clock phase issue (but I don't think that's exactly the same problem as what we see here.)
Ok, that could be the missing inverter I had hoped that it can be software controlled... Adding one in hardware would be more difficult than the missing capacitor :(
There are also the OMAP IO drive strength and slew settings to play with though.
Indeed. If the drive strengh is higher the slew rate is higher and the risk of sampling the wrong value should go down. Let's hope it goes this way...
BR, Nikolaus
Am 30.07.2020 um 12:20 schrieb H. Nikolaus Schaller < hns@goldelico.com>:
Wow! Maybe you can ask Peter Ujfalusi as he has done a lot of previous work for twl audio.
I'll check all this as soon as I find time.
BR and thanks, Nikolaus
Am 30.07.2020 um 12:15 schrieb David Shah dave@ds0.me:
Well, I seem to have found a solution. It is totally and utterly inexplicable, but there you go.
The OMAP5 TRM says that the input buffer for MCPDM_LB_CLK - the clock going out from the OMAP5 to the TWL, that clocks the PDM stream and mirrors the TWL clock output - must be enabled; as the input signal is used internally for retiming purposes.
But using devmem2 to DISABLE this input buffer, against the TRM advice, seems to fix the stream desynchronisation issue!
# devmem2 0x4A0029A0 w 0x0080118
There is still a quiet a crackle when the vibra turns on or off, which really does seem like switching noise from the motor, but the stream is never actually corrupted and the crackle does not disrupt what is playing!
I'm done with OMAP stuff for today :) but I'll experiment more over the weekend. If you get a chance, I would be interested to see if this is reproducible on your unit, too.
I need to think a bit more about how this could actually look from a silicon point of view to see if there is a better fix. It is possible that disabling the input buffer means that the OMAP5 is using some internal clock instead that isn't disrupted by noise on the pad.
It could also be related to OAMP5 errata i800 / TWL errata 6, which involves relative clock phases. I had ruled that out because it would be odd for power supply noise to affect that; and it reads more like dropped/duplicated samples than total loss of stream.
Best
David
On Wed, 2020-07-29 at 18:32 +0100, David Shah wrote: > Hi Nikolaus, > > Couple of thoughts below. > > On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus Schaller > wrote: >>> Am 29.07.2020 um 18:58 schrieb H. Nikolaus Schaller < >>> hns@goldelico.com>: >>> >>> >>>> Am 29.07.2020 um 18:04 schrieb David Shah < >>>> dave@ds0.me>: >>>> >>>> Hi all, >>>> >>>> I tried adding a 470nF 0402 capacitor in what I hope >>>> was >>>> the >>>> right >>>> place (see attached), >>> >>> yes, from a first glance it looks to be right! >>> >>>> and replacing the associated resistor with a >>>> short. Sadly that made no difference, but maybe 470n >>>> isn't high >>>> enough >>>> (I also have 4.7u 0805 but I suspect that might be >>>> too >>>> tall. >>> >>> Hm. I hope I find some minutes to open my sample and >>> try >>> the >>> same. >>> Then we know. >> >> Here is a full picture where I tried tp mimic the >> colours: >> > > Yes, that matches what I did. > >> Maybe the copper trace between the C and the R is too >> small. >> So a >> wire directly >> across all three solder pads could be better. Or >> scratching >> off the >> solder mask from >> the ground plane around and soldering the capacitor >> directly >> to >> GND. >> > > In my second attempt with 4.7u, I did effectively end up > with > one > solder blob all the way across that should be pretty low > impedance. > >> If I find time (which is unfortunately unlikely) I could >> add >> two >> wires to the pads of the >> capacitor and get them outside the Pyra to be able to >> measure >> the >> voltage with the oscilloscope. >> >> Some thoughts about the software side: I remember that >> Peter >> Ujfalusi >> long time ago mentioned >> different clocks. Maybe the 32kHz clock or the McPDM >> clock >> which >> could be used as a >> reference. And there was a kernel version where sound >> became >> a >> little >> better (but I wouldn't >> bet for it). So there may still be another effect in >> software. >> Maybe >> in addition so that >> what we observe is the sum of several effects. >> > > Interesting, the clocking definitely isn't quite right in > the > latest > as > high power mode also used to work on 4.19 but doesn't seem > to > any > more. > >> One question about the loopback: does it show if the PCM >> data >> is >> coming in the right >> and stable timing? E.g. speed may fluctuate but still >> provide >> perfect >> data mirroring. >> Nevertheless, fluctuating speed may become audible. >> > > This is true, there is some possibility for "common mode > failure" > that > would symmetrically affect both directions. > >> But it is difficult to see how this would be influenced >> by >> the >> Vibra. >> Well, the Vibra >> is also controlled through some PCM channel because the >> motor >> can >> "play" the bass sound... >> > The Vibra seems to be set to "Input FF" mode by default > AIUI it > is > controlled by I2C not the PDM stream when using vibra.py. > But > you can > set it to PDM mode in alsamixer which seems to turn it > always > on > (presumably a 1 is sent in the PDM stream for that channel > by > default?) > noise that always goes away as soon as you turn it off > again > rather > than glitching the stream. > > It also seems to differ significantly less depending on the > volume > setting - it isn't directly scaled by volume in the same > way as > Vibra > Right glitching is; as if it is affecting something later > in > the > signal > path. > > Strange that an unconnected channel also makes a > difference, > but the > H- > bridge is still presumably still switching and any H-bridge > does > produce some shoot-through noise. > > I am wondering now if some config issue is making the TWL > much > more > sensitive than it should be for some reason. > > Best > > David > >>>> I'm still proud to own the first modded Pyra, even >>>> though >>>> it >>>> didn't >>>> work :D >>> >>> ++ >>> >>> BR, Nikolaus >>> >>>> Best >>>> >>>> David >>>> >>>> On Wed, 2020-07-29 at 17:37 +0200, Michael Mrozek >>>> wrote: >>>>> Am Mittwoch, den 29.07.2020, 17:25 +0200 schrieb H. >>>>> Nikolaus >>>>> Schaller: >>>>> >>>>> Hi, >>>>> >>>>>> 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. >>>>> >>>>> Oh, that's good news! >>>>> Can you let me know where to solder them so I'll >>>>> try >>>>> that >>>>> here? >>>>> >>>>>> 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. >>>>> >>>>> Well, we tested various materials between the CPU >>>>> board >>>>> and >>>>> the >>>>> plastics - but >>>>> the best solution is to put NOTHING in between. >>>>> >>>>> If we put a metal sheet in there, the heat goes >>>>> into >>>>> the >>>>> metal >>>>> and >>>>> heats the >>>>> battery - whereas almost nothing moves into the >>>>> heatsink >>>>> (where >>>>> it >>>>> should). >>>>> >>>>> So there's a gap of 0.4mm between the CPU board and >>>>> the >>>>> backside, and >>>>> as the >>>>> keymat acts a bit like a cushion as well, I guess a >>>>> small >>>>> part >>>>> like a >>>>> capacitor >>>>> could even use up to 0.6 to 0.7mm. >>>>> >>>>> So there should be enough space to put a small >>>>> capacitor in >>>>> there. >>>>> >>>>>> 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). >>>>> >>>>> We have 500 already-produced PCBs - so I guess we'd >>>>> need to >>>>> fix >>>>> these >>>>> manually. >>>>> But hey, MWeston had to replace 500 capacitors on >>>>> the >>>>> Pandora >>>>> PCBs >>>>> manually as >>>>> well. >>>>> >>>>> Only bigger downside would be that we have another >>>>> setup >>>>> costs >>>>> for >>>>> the next CPU >>>>> boards... that's around 5000 EUR alltogether :/ >>>>> >>>>> >>>> <photo_2020-07-29_17-03-18.jpg> >>> >>> _______________________________________________ >>> Kernel mailing list >>> Kernel@pyra-handheld.com >>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
1. My previous loopback experiment was not correct for some reason (I think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
2. I tried deliberately glitching the ABE_CLKS signal (from TWL to OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint. This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.
On Thu, 2020-07-30 at 20:37 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 20:29 schrieb David Shah dave@ds0.me:
A tiny bit more insight.
It also seems possible to stop the glitching by disabling the _up_link channels on the OMAP side, either by clearing PDM_UP[1-3]_EN or setting SW_UP_RST in MCPDM_CTRL.
This actually seems slightly more reliable than disabling the loopback clock input buffer. But I suspect disabling that input buffer also breaks the uplink path, I haven't tried yet.
Disabling the uplink by disabling the uplink data input buffer, on the other hand, does not fix the glitching, so the glitching is not some strange result of the uplink data stream itself. Instead there must be some strange cross-connection between the up and down link in the OMAP5 that gets messed up by electrical noise (???). All the more mysterious...
That is certainly something to discuss with TI people (Peter Ujfalusi is still active - sent a mail a week ago about "omap-mcbsp 49022000.mcbsp: TX Buffer Overflow!").
As a worst case scenario, a patch that fully disabled the uplink channels when not being used would already improve reliability a lot. The mechanical noise of the vibra would make the internal microphone useless anyway.
Not necessarily since the mic has a sound guide and small hole on the left side of the keyboard. So it may be possible to hear the rumble but it would not make the recorded sound useless. It may even be possible to do noise cancelling for the vibra activities through aess (yes I know it is a dream)...
Best regards, Nikolaus
Best
David
On Thu, 2020-07-30 at 13:10 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 13:02 schrieb David Shah dave@ds0.me:
On Thu, 2020-07-30 at 12:37 +0200, H. Nikolaus Schaller wrote:
Yes, I can confirm the effect.
After doing devmem2 0x4A0029A0 w 0x0080118 sound output stops (but aplay continues to run without notice about buffer under/overflow or alike). After restarting aplay sound is better. And vibra influence is no longer noticeable. Restoring devmem2 0x4A0029A0 w 0x1080118 makes problem come back
even while aplay runs. But still it depends on volume. So high volume + 0x1080118 is unreliable.
Hm. Is there a clock polarity setting? Either in McPDM or the twl6040? If clock polarity would be wrong, then it may depend on power supply noise if the data line is sampled correctly and the previous bit value creeps in or some random bit is read.
As far as I know there isn't one; the errata does suggest adding an external inverter to work around a clock phase issue (but I don't think that's exactly the same problem as what we see here.)
Ok, that could be the missing inverter I had hoped that it can be software controlled... Adding one in hardware would be more difficult than the missing capacitor :(
There are also the OMAP IO drive strength and slew settings to play with though.
Indeed. If the drive strengh is higher the slew rate is higher and the risk of sampling the wrong value should go down. Let's hope it goes this way...
BR, Nikolaus
Am 30.07.2020 um 12:20 schrieb H. Nikolaus Schaller < hns@goldelico.com>:
Wow! Maybe you can ask Peter Ujfalusi as he has done a lot of previous work for twl audio.
I'll check all this as soon as I find time.
BR and thanks, Nikolaus
> Am 30.07.2020 um 12:15 schrieb David Shah dave@ds0.me: > > Well, I seem to have found a solution. It is totally and > utterly > inexplicable, but there you go. > > The OMAP5 TRM says that the input buffer for MCPDM_LB_CLK > - > the > clock > going out from the OMAP5 to the TWL, that clocks the PDM > stream > and > mirrors the TWL clock output - must be enabled; as the > input > signal is > used internally for retiming purposes. > > But using devmem2 to DISABLE this input buffer, against > the > TRM > advice, > seems to fix the stream desynchronisation issue! > > # devmem2 0x4A0029A0 w 0x0080118 > > There is still a quiet a crackle when the vibra turns on > or > off, > which > really does seem like switching noise from the motor, but > the > stream is > never actually corrupted and the crackle does not disrupt > what is > playing! > > I'm done with OMAP stuff for today :) but I'll experiment > more > over the > weekend. If you get a chance, I would be interested to > see if > this is > reproducible on your unit, too. > > I need to think a bit more about how this could actually > look > from a > silicon point of view to see if there is a better fix. It > is > possible > that disabling the input buffer means that the OMAP5 is > using > some > internal clock instead that isn't disrupted by noise on > the > pad. > > It could also be related to OAMP5 errata i800 / TWL > errata 6, > which > involves relative clock phases. I had ruled that out > because > it > would > be odd for power supply noise to affect that; and it > reads > more > like > dropped/duplicated samples than total loss of stream. > > Best > > David > > > On Wed, 2020-07-29 at 18:32 +0100, David Shah wrote: > > Hi Nikolaus, > > > > Couple of thoughts below. > > > > On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus Schaller > > wrote: > > > > Am 29.07.2020 um 18:58 schrieb H. Nikolaus Schaller > > > > < > > > > hns@goldelico.com>: > > > > > > > > > > > > > Am 29.07.2020 um 18:04 schrieb David Shah < > > > > > dave@ds0.me>: > > > > > > > > > > Hi all, > > > > > > > > > > I tried adding a 470nF 0402 capacitor in what I > > > > > hope > > > > > was > > > > > the > > > > > right > > > > > place (see attached), > > > > > > > > yes, from a first glance it looks to be right! > > > > > > > > > and replacing the associated resistor with a > > > > > short. Sadly that made no difference, but maybe > > > > > 470n > > > > > isn't high > > > > > enough > > > > > (I also have 4.7u 0805 but I suspect that might > > > > > be > > > > > too > > > > > tall. > > > > > > > > Hm. I hope I find some minutes to open my sample > > > > and > > > > try > > > > the > > > > same. > > > > Then we know. > > > > > > Here is a full picture where I tried tp mimic the > > > colours: > > > > > > > Yes, that matches what I did. > > > > > Maybe the copper trace between the C and the R is too > > > small. > > > So a > > > wire directly > > > across all three solder pads could be better. Or > > > scratching > > > off the > > > solder mask from > > > the ground plane around and soldering the capacitor > > > directly > > > to > > > GND. > > > > > > > In my second attempt with 4.7u, I did effectively end > > up > > with > > one > > solder blob all the way across that should be pretty > > low > > impedance. > > > > > If I find time (which is unfortunately unlikely) I > > > could > > > add > > > two > > > wires to the pads of the > > > capacitor and get them outside the Pyra to be able to > > > measure > > > the > > > voltage with the oscilloscope. > > > > > > Some thoughts about the software side: I remember > > > that > > > Peter > > > Ujfalusi > > > long time ago mentioned > > > different clocks. Maybe the 32kHz clock or the McPDM > > > clock > > > which > > > could be used as a > > > reference. And there was a kernel version where sound > > > became > > > a > > > little > > > better (but I wouldn't > > > bet for it). So there may still be another effect in > > > software. > > > Maybe > > > in addition so that > > > what we observe is the sum of several effects. > > > > > > > Interesting, the clocking definitely isn't quite right > > in > > the > > latest > > as > > high power mode also used to work on 4.19 but doesn't > > seem > > to > > any > > more. > > > > > One question about the loopback: does it show if the > > > PCM > > > data > > > is > > > coming in the right > > > and stable timing? E.g. speed may fluctuate but still > > > provide > > > perfect > > > data mirroring. > > > Nevertheless, fluctuating speed may become audible. > > > > > > > This is true, there is some possibility for "common > > mode > > failure" > > that > > would symmetrically affect both directions. > > > > > But it is difficult to see how this would be > > > influenced > > > by > > > the > > > Vibra. > > > Well, the Vibra > > > is also controlled through some PCM channel because > > > the > > > motor > > > can > > > "play" the bass sound... > > > > > The Vibra seems to be set to "Input FF" mode by default > > AIUI it > > is > > controlled by I2C not the PDM stream when using > > vibra.py. > > But > > you can > > set it to PDM mode in alsamixer which seems to turn it > > always > > on > > (presumably a 1 is sent in the PDM stream for that > > channel > > by > > default?) > > noise that always goes away as soon as you turn it off > > again > > rather > > than glitching the stream. > > > > It also seems to differ significantly less depending on > > the > > volume > > setting - it isn't directly scaled by volume in the > > same > > way as > > Vibra > > Right glitching is; as if it is affecting something > > later > > in > > the > > signal > > path. > > > > Strange that an unconnected channel also makes a > > difference, > > but the > > H- > > bridge is still presumably still switching and any H- > > bridge > > does > > produce some shoot-through noise. > > > > I am wondering now if some config issue is making the > > TWL > > much > > more > > sensitive than it should be for some reason. > > > > Best > > > > David > > > > > > > I'm still proud to own the first modded Pyra, > > > > > even > > > > > though > > > > > it > > > > > didn't > > > > > work :D > > > > > > > > ++ > > > > > > > > BR, Nikolaus > > > > > > > > > Best > > > > > > > > > > David > > > > > > > > > > On Wed, 2020-07-29 at 17:37 +0200, Michael Mrozek > > > > > wrote: > > > > > > Am Mittwoch, den 29.07.2020, 17:25 +0200 > > > > > > schrieb H. > > > > > > Nikolaus > > > > > > Schaller: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > 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. > > > > > > > > > > > > Oh, that's good news! > > > > > > Can you let me know where to solder them so > > > > > > I'll > > > > > > try > > > > > > that > > > > > > here? > > > > > > > > > > > > > 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. > > > > > > > > > > > > Well, we tested various materials between the > > > > > > CPU > > > > > > board > > > > > > and > > > > > > the > > > > > > plastics - but > > > > > > the best solution is to put NOTHING in between. > > > > > > > > > > > > If we put a metal sheet in there, the heat goes > > > > > > into > > > > > > the > > > > > > metal > > > > > > and > > > > > > heats the > > > > > > battery - whereas almost nothing moves into the > > > > > > heatsink > > > > > > (where > > > > > > it > > > > > > should). > > > > > > > > > > > > So there's a gap of 0.4mm between the CPU board > > > > > > and > > > > > > the > > > > > > backside, and > > > > > > as the > > > > > > keymat acts a bit like a cushion as well, I > > > > > > guess a > > > > > > small > > > > > > part > > > > > > like a > > > > > > capacitor > > > > > > could even use up to 0.6 to 0.7mm. > > > > > > > > > > > > So there should be enough space to put a small > > > > > > capacitor in > > > > > > there. > > > > > > > > > > > > > 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). > > > > > > > > > > > > We have 500 already-produced PCBs - so I guess > > > > > > we'd > > > > > > need to > > > > > > fix > > > > > > these > > > > > > manually. > > > > > > But hey, MWeston had to replace 500 capacitors > > > > > > on > > > > > > the > > > > > > Pandora > > > > > > PCBs > > > > > > manually as > > > > > > well. > > > > > > > > > > > > Only bigger downside would be that we have > > > > > > another > > > > > > setup > > > > > > costs > > > > > > for > > > > > > the next CPU > > > > > > boards... that's around 5000 EUR alltogether :/ > > > > > > > > > > > > > > > > > <photo_2020-07-29_17-03-18.jpg> > > > > > > > > _______________________________________________ > > > > Kernel mailing list > > > > Kernel@pyra-handheld.com > > > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > > > > _______________________________________________ > > Kernel mailing list > > Kernel@pyra-handheld.com > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Fri, 31 Jul 2020 15:38:50 +0100 hat David Shah dave@ds0.me geschrieben:
Hi,
hmm, I wonder if this does also appear when using AESS.
From an older post by Peter in the mailinglist (https://www.pyra-handheld.com/pipermail/kernel/2014-September/000420.html)
"The 'plop' is known side effect of using dumb McPDM <-> twl6040. OMAP4 and twl6040 was developed together to provide a solution: McPDM is a new protocol only used by OMAP4/5. In short: there's a 'feature' in twl6040 that it interprets the the signal on the bus as data when OMAP stats to take it over. The 'plop' can only be fixed if you are using AESS. With AESS in use the stream starts and stops are silent and you have native support for wider array of sampling frequencies, separate PCMs for Headset, Handsfree, low-power playback mode (called ping-pong) signal mixing (tone, music)."
It seems McPDM in combination can do a lot more than in the current "dumb" mode we use. Maybe it also has some checksums / error recovery / whatever included...?
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
- My previous loopback experiment was not correct for some reason (I
think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
- I tried deliberately glitching the ABE_CLKS signal (from TWL to
OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint. This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.
On Thu, 2020-07-30 at 20:37 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 20:29 schrieb David Shah dave@ds0.me:
A tiny bit more insight.
It also seems possible to stop the glitching by disabling the _up_link channels on the OMAP side, either by clearing PDM_UP[1-3]_EN or setting SW_UP_RST in MCPDM_CTRL.
This actually seems slightly more reliable than disabling the loopback clock input buffer. But I suspect disabling that input buffer also breaks the uplink path, I haven't tried yet.
Disabling the uplink by disabling the uplink data input buffer, on the other hand, does not fix the glitching, so the glitching is not some strange result of the uplink data stream itself. Instead there must be some strange cross-connection between the up and down link in the OMAP5 that gets messed up by electrical noise (???). All the more mysterious...
That is certainly something to discuss with TI people (Peter Ujfalusi is still active - sent a mail a week ago about "omap-mcbsp 49022000.mcbsp: TX Buffer Overflow!").
As a worst case scenario, a patch that fully disabled the uplink channels when not being used would already improve reliability a lot. The mechanical noise of the vibra would make the internal microphone useless anyway.
Not necessarily since the mic has a sound guide and small hole on the left side of the keyboard. So it may be possible to hear the rumble but it would not make the recorded sound useless. It may even be possible to do noise cancelling for the vibra activities through aess (yes I know it is a dream)...
Best regards, Nikolaus
Best
David
On Thu, 2020-07-30 at 13:10 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 13:02 schrieb David Shah dave@ds0.me:
On Thu, 2020-07-30 at 12:37 +0200, H. Nikolaus Schaller wrote:
Yes, I can confirm the effect.
After doing devmem2 0x4A0029A0 w 0x0080118 sound output stops (but aplay continues to run without notice about buffer under/overflow or alike). After restarting aplay sound is better. And vibra influence is no longer noticeable. Restoring devmem2 0x4A0029A0 w 0x1080118 makes problem come back
even while aplay runs. But still it depends on volume. So high volume + 0x1080118 is unreliable.
Hm. Is there a clock polarity setting? Either in McPDM or the twl6040? If clock polarity would be wrong, then it may depend on power supply noise if the data line is sampled correctly and the previous bit value creeps in or some random bit is read.
As far as I know there isn't one; the errata does suggest adding an external inverter to work around a clock phase issue (but I don't think that's exactly the same problem as what we see here.)
Ok, that could be the missing inverter I had hoped that it can be software controlled... Adding one in hardware would be more difficult than the missing capacitor :(
There are also the OMAP IO drive strength and slew settings to play with though.
Indeed. If the drive strengh is higher the slew rate is higher and the risk of sampling the wrong value should go down. Let's hope it goes this way...
BR, Nikolaus
> Am 30.07.2020 um 12:20 schrieb H. Nikolaus Schaller < > hns@goldelico.com>: > > Wow! > Maybe you can ask Peter Ujfalusi as he has done a lot of > previous > work for twl audio. > > I'll check all this as soon as I find time. > > BR and thanks, > Nikolaus > > > Am 30.07.2020 um 12:15 schrieb David Shah dave@ds0.me: > > > > Well, I seem to have found a solution. It is totally and > > utterly > > inexplicable, but there you go. > > > > The OMAP5 TRM says that the input buffer for > > MCPDM_LB_CLK - > > the > > clock > > going out from the OMAP5 to the TWL, that clocks the PDM > > stream > > and > > mirrors the TWL clock output - must be enabled; as the > > input > > signal is > > used internally for retiming purposes. > > > > But using devmem2 to DISABLE this input buffer, against > > the > > TRM > > advice, > > seems to fix the stream desynchronisation issue! > > > > # devmem2 0x4A0029A0 w 0x0080118 > > > > There is still a quiet a crackle when the vibra turns on > > or > > off, > > which > > really does seem like switching noise from the motor, > > but the > > stream is > > never actually corrupted and the crackle does not > > disrupt what is > > playing! > > > > I'm done with OMAP stuff for today :) but I'll > > experiment more > > over the > > weekend. If you get a chance, I would be interested to > > see if > > this is > > reproducible on your unit, too. > > > > I need to think a bit more about how this could actually > > look > > from a > > silicon point of view to see if there is a better fix. > > It is > > possible > > that disabling the input buffer means that the OMAP5 is > > using > > some > > internal clock instead that isn't disrupted by noise on > > the > > pad. > > > > It could also be related to OAMP5 errata i800 / TWL > > errata 6, > > which > > involves relative clock phases. I had ruled that out > > because > > it > > would > > be odd for power supply noise to affect that; and it > > reads > > more > > like > > dropped/duplicated samples than total loss of stream. > > > > Best > > > > David > > > > > > On Wed, 2020-07-29 at 18:32 +0100, David Shah wrote: > > > Hi Nikolaus, > > > > > > Couple of thoughts below. > > > > > > On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus > > > Schaller wrote: > > > > > Am 29.07.2020 um 18:58 schrieb H. Nikolaus > > > > > Schaller < > > > > > hns@goldelico.com>: > > > > > > > > > > > > > > > > Am 29.07.2020 um 18:04 schrieb David Shah < > > > > > > dave@ds0.me>: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I tried adding a 470nF 0402 capacitor in what I > > > > > > hope > > > > > > was > > > > > > the > > > > > > right > > > > > > place (see attached), > > > > > > > > > > yes, from a first glance it looks to be right! > > > > > > > > > > > and replacing the associated resistor with a > > > > > > short. Sadly that made no difference, but maybe > > > > > > 470n > > > > > > isn't high > > > > > > enough > > > > > > (I also have 4.7u 0805 but I suspect that might > > > > > > be > > > > > > too > > > > > > tall. > > > > > > > > > > Hm. I hope I find some minutes to open my sample > > > > > and > > > > > try > > > > > the > > > > > same. > > > > > Then we know. > > > > > > > > Here is a full picture where I tried tp mimic the > > > > colours: > > > > > > > > > > Yes, that matches what I did. > > > > > > > Maybe the copper trace between the C and the R is > > > > too small. > > > > So a > > > > wire directly > > > > across all three solder pads could be better. Or > > > > scratching > > > > off the > > > > solder mask from > > > > the ground plane around and soldering the capacitor > > > > directly > > > > to > > > > GND. > > > > > > > > > > In my second attempt with 4.7u, I did effectively end > > > up > > > with > > > one > > > solder blob all the way across that should be pretty > > > low > > > impedance. > > > > > > > If I find time (which is unfortunately unlikely) I > > > > could > > > > add > > > > two > > > > wires to the pads of the > > > > capacitor and get them outside the Pyra to be able > > > > to measure > > > > the > > > > voltage with the oscilloscope. > > > > > > > > Some thoughts about the software side: I remember > > > > that > > > > Peter > > > > Ujfalusi > > > > long time ago mentioned > > > > different clocks. Maybe the 32kHz clock or the McPDM > > > > clock > > > > which > > > > could be used as a > > > > reference. And there was a kernel version where > > > > sound became > > > > a > > > > little > > > > better (but I wouldn't > > > > bet for it). So there may still be another effect in > > > > software. > > > > Maybe > > > > in addition so that > > > > what we observe is the sum of several effects. > > > > > > > > > > Interesting, the clocking definitely isn't quite right > > > in > > > the > > > latest > > > as > > > high power mode also used to work on 4.19 but doesn't > > > seem > > > to > > > any > > > more. > > > > > > > One question about the loopback: does it show if the > > > > PCM > > > > data > > > > is > > > > coming in the right > > > > and stable timing? E.g. speed may fluctuate but > > > > still provide > > > > perfect > > > > data mirroring. > > > > Nevertheless, fluctuating speed may become audible. > > > > > > > > > > This is true, there is some possibility for "common > > > mode > > > failure" > > > that > > > would symmetrically affect both directions. > > > > > > > But it is difficult to see how this would be > > > > influenced > > > > by > > > > the > > > > Vibra. > > > > Well, the Vibra > > > > is also controlled through some PCM channel because > > > > the > > > > motor > > > > can > > > > "play" the bass sound... > > > > > > > The Vibra seems to be set to "Input FF" mode by > > > default AIUI it > > > is > > > controlled by I2C not the PDM stream when using > > > vibra.py. > > > But > > > you can > > > set it to PDM mode in alsamixer which seems to turn it > > > always > > > on > > > (presumably a 1 is sent in the PDM stream for that > > > channel > > > by > > > default?) > > > noise that always goes away as soon as you turn it off > > > again > > > rather > > > than glitching the stream. > > > > > > It also seems to differ significantly less depending > > > on the > > > volume > > > setting - it isn't directly scaled by volume in the > > > same > > > way as > > > Vibra > > > Right glitching is; as if it is affecting something > > > later > > > in > > > the > > > signal > > > path. > > > > > > Strange that an unconnected channel also makes a > > > difference, > > > but the > > > H- > > > bridge is still presumably still switching and any H- > > > bridge > > > does > > > produce some shoot-through noise. > > > > > > I am wondering now if some config issue is making the > > > TWL > > > much > > > more > > > sensitive than it should be for some reason. > > > > > > Best > > > > > > David > > > > > > > > > I'm still proud to own the first modded Pyra, > > > > > > even > > > > > > though > > > > > > it > > > > > > didn't > > > > > > work :D > > > > > > > > > > ++ > > > > > > > > > > BR, Nikolaus > > > > > > > > > > > Best > > > > > > > > > > > > David > > > > > > > > > > > > On Wed, 2020-07-29 at 17:37 +0200, Michael > > > > > > Mrozek wrote: > > > > > > > Am Mittwoch, den 29.07.2020, 17:25 +0200 > > > > > > > schrieb H. > > > > > > > Nikolaus > > > > > > > Schaller: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Oh, that's good news! > > > > > > > Can you let me know where to solder them so > > > > > > > I'll > > > > > > > try > > > > > > > that > > > > > > > here? > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Well, we tested various materials between the > > > > > > > CPU > > > > > > > board > > > > > > > and > > > > > > > the > > > > > > > plastics - but > > > > > > > the best solution is to put NOTHING in > > > > > > > between. > > > > > > > > > > > > > > If we put a metal sheet in there, the heat > > > > > > > goes into > > > > > > > the > > > > > > > metal > > > > > > > and > > > > > > > heats the > > > > > > > battery - whereas almost nothing moves into > > > > > > > the heatsink > > > > > > > (where > > > > > > > it > > > > > > > should). > > > > > > > > > > > > > > So there's a gap of 0.4mm between the CPU > > > > > > > board and > > > > > > > the > > > > > > > backside, and > > > > > > > as the > > > > > > > keymat acts a bit like a cushion as well, I > > > > > > > guess a > > > > > > > small > > > > > > > part > > > > > > > like a > > > > > > > capacitor > > > > > > > could even use up to 0.6 to 0.7mm. > > > > > > > > > > > > > > So there should be enough space to put a small > > > > > > > capacitor in > > > > > > > there. > > > > > > > > > > > > > > > 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). > > > > > > > > > > > > > > We have 500 already-produced PCBs - so I guess > > > > > > > we'd > > > > > > > need to > > > > > > > fix > > > > > > > these > > > > > > > manually. > > > > > > > But hey, MWeston had to replace 500 capacitors > > > > > > > on > > > > > > > the > > > > > > > Pandora > > > > > > > PCBs > > > > > > > manually as > > > > > > > well. > > > > > > > > > > > > > > Only bigger downside would be that we have > > > > > > > another > > > > > > > setup > > > > > > > costs > > > > > > > for > > > > > > > the next CPU > > > > > > > boards... that's around 5000 EUR > > > > > > > alltogether :/ > > > > > > > > > > > > > > > > > > > > <photo_2020-07-29_17-03-18.jpg> > > > > > > > > > > _______________________________________________ > > > > > Kernel mailing list > > > > > Kernel@pyra-handheld.com > > > > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > > > > > > _______________________________________________ > > > Kernel mailing list > > > Kernel@pyra-handheld.com > > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Fri, 31 Jul 2020 15:38:50 +0100 hat David Shah dave@ds0.me geschrieben:
And now for some more weirdness in this regard: https://www.youtube.com/watch?v=BZcFnunrVGw
This video has been recorded July 2016, using the Letux OS that was available back then.
I know the speakers were physically overdriving when going higher than 75% (no sealing yet), but I can't remember that they ever glitched. And at least on this video, they were running fine on 75% volume...
It COULD be they had the issue back then and I simply forgot - but I think it simply didn't happen back then.
Question is: What kernel version did that use? On the Letux GIT I can see that we had 3.12.x and as next kernel 4.9.x.
I'm not sure if that means Letux didn't have any 4.x kernel before 4.9.x (Nikolaus, that's a question for you to answer :))
4.9 was released December 2016 - so after that video.
That means that the kernel used in this video was most probably a 3.12.x one.
On 3.12, AESS was still supported and working.
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
- My previous loopback experiment was not correct for some reason (I
think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
- I tried deliberately glitching the ABE_CLKS signal (from TWL to
OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint. This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.
Am 31.07.2020 um 18:28 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Fri, 31 Jul 2020 15:38:50 +0100 hat David Shah dave@ds0.me geschrieben:
And now for some more weirdness in this regard: https://www.youtube.com/watch?v=BZcFnunrVGw
This video has been recorded July 2016, using the Letux OS that was available back then.
I know the speakers were physically overdriving when going higher than 75% (no sealing yet), but I can't remember that they ever glitched. And at least on this video, they were running fine on 75% volume...
It COULD be they had the issue back then and I simply forgot - but I think it simply didn't happen back then.
Question is: What kernel version did that use? On the Letux GIT I can see that we had 3.12.x and as next kernel 4.9.x.
These are only the longterm / stable kernels. There have been many versions in between.
I'm not sure if that means Letux didn't have any 4.x kernel before 4.9.x (Nikolaus, that's a question for you to answer :))
4.9 was released December 2016 - so after that video.
There is an archive of all (well almost all) versions that did exist:
letux-4.8.11/ 2016-11-28 10:01 - letux-4.9-rc6-lpae/ 2016-11-22 07:55 - letux-4.9-rc6/ 2016-11-21 19:52 - letux-4.9-rc5-lpae/ 2016-11-14 17:27 - letux-4.9-rc5/ 2016-11-14 14:45 - letux-4.9-rc4/ 2016-11-07 10:41 - letux-4.9-rc3/ 2016-10-30 17:26 - letux-4.9-rc2/ 2016-10-24 10:31 - letux-4.8.4/ 2016-10-22 15:57 - letux-4.8.3/ 2016-10-21 12:46 - letux-4.9-rc1/ 2016-10-16 23:08 - letux-4.8.1/ 2016-10-08 10:12 - letux-4.8/ 2016-10-03 10:45 - letux-4.8-rc8/ 2016-09-26 10:17 - letux-4.8-rc7/ 2016-09-21 12:46 - letux-4.8-rc6/ 2016-09-12 11:33 - letux-4.8-rc1/ 2016-08-11 15:03 - letux-4.7/ 2016-07-27 16:46 - letux-4.7-rc7/ 2016-07-11 10:47 - letux-4.7-rc6/ 2016-07-06 14:07 - letux-4.7-rc5/ 2016-06-27 15:35 - letux-4.7-rc4/ 2016-06-20 15:08 - letux-4.7-rc3/ 2016-06-13 09:23 - letux-4.7-rc2/ 2016-06-08 10:21 - letux-4.7-rc1/ 2016-06-01 01:02 - letux-4.6/ 2016-05-31 23:05 - letux-4.6-rc6/ 2016-05-02 12:35 - letux-4.6-rc5/ 2016-04-25 16:44 - letux-4.6-rc4/ 2016-04-18 19:04 - letux-4.6-rc3/ 2016-04-13 22:41 - letux-4.6-rc2/ 2016-04-08 00:50 - letux-4.5/ 2016-03-30 20:59 - letux-4.5-rc2/ 2016-02-02 12:12 - letux-4.4/ 2016-01-11 11:53 - letux-4.4-rc8/ 2016-01-04 11:28 - letux-4.4-rc5/ 2015-12-21 10:16 -
So most likely it could have been letux-4.7 since it has the same date as the video.
Well, we have to check if that old kernel is still running with user-space or has some dependencies.
The kernel tree is here:
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-...
There seems to be a device tree for the pyra - but that is for one of the first prototypes (V5.0) only:
https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=arch/arm/boot/dts/oma...
What is quite sure is that it was a 2GB RAM processor and not built as LPAE (that started with 4.9 builds).
Making this setup work again on modern hardware is a quite big task.
It would also be good to backport some recent findings (like making "reboot" work). And the most challenging part is to backport the device tree to support the mass production hardware.
Another issue is that I do not know what u-boot we did use.
That means that the kernel used in this video was most probably a 3.12.x one.
No, I think we never had a 3.12 working on the Pyra. The first V5.0 boards were produced end of 2015. And V5.1 boards were ordered in July 2016.
On 3.12, AESS was still supported and working.
But we never had AESS working. AESS probably will not help since it is more a sound signal processor, mixer, equalizer, echo canceller. It can't solve PCM communication issues and relies on stable McPDM communication. Unless it works around a hardware bug in the omap5 by good luck.
But generally you are right, I also remember that there were kernels without this scratchy effect and it creeped in sometimes (and disappeared in later kernels until David tried to run the rumble in parallel).
Ah, I also had once connected a "big" 8 Ohm speaker to the handsfree output and there, sound was perfect. Which we took as indication that the speakers or how they are mounted is not perfect.
So it still might be a software issue (but AESS is IMHO not part of the solution).
Or we were simply lucky with those first V5.0 prototypes.
BR, Nikolaus
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
- My previous loopback experiment was not correct for some reason (I
think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
- I tried deliberately glitching the ABE_CLKS signal (from TWL to
OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint. This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
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-...
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.
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.
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-...
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-...
Hi Nikolaus,
One last PCB question. Is R2102 populated on production boards, if so, 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.
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
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
I notice that on the connector, the reference clock is next to the vibra signals, which would explain the coupling between them. 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.
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
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...
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.
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
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
On Sa, 2020-08-01 at 16:44 +0100, David Shah wrote:
Hi,
I can try that - but I'm not that good with reading gerber files... if I can get a picture of the PCB area or a some clear mark on these pictures what resistor I need to remove, then I'll check :)
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
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
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.BestDavid
-------- 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 forthe 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
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
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> >
On Mo, 2020-10-19 at 15:17 +0100, dave wrote:
Okay, finally found the time to work on this. The CPU board I tried worked fine with audio - but as expected, the audio stream crashed as soon as vibra was on.
A good candidate to remove the resistor!
And guess what: It worked.
I can now listen to music while using the vibra.py to cause the Pyra to vibrate - and the stream didn't crash :)
Maybe some of you can test that as well. Removing the resistor is easy - I barely touched it with my soldering iron and it fell off.
You can probably even remove it simply with some scalpel or sharp knife and without soldering iron.
Now, there's only one issue left: Noise on the headset. As soon as the stream is enabled, you can hear noise on the headset (when audio is silent - if you listen to music, you can't hear it anymore).
However, there's something weird I did notice: Even on Headset volume 0 in AlsaMixer, audio is pretty loud! In fact, it's probably the maximum volume I would personally use.
So something seems to increase the volume even though you set it to 0 in AlsaMixer.
I do wonder - is that some additional amplifier inside the TWL that is always switched on? Or why is the volume that loud?
If that's the case, maybe the audio noise would be gone as well as soon as we switch that off.
Any ideas?
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> >
On 07/11/2020 21.16, Michael Mrozek wrote:
On Mo, 2020-10-19 at 15:17 +0100, dave wrote:
Okay, finally found the time to work on this. The CPU board I tried worked fine with audio - but as expected, the audio stream crashed as soon as vibra was on.
A good candidate to remove the resistor!
And guess what: It worked.
I can now listen to music while using the vibra.py to cause the Pyra to vibrate - and the stream didn't crash :)
Maybe some of you can test that as well. Removing the resistor is easy
- I barely touched it with my soldering iron and it fell off.
You can probably even remove it simply with some scalpel or sharp knife and without soldering iron.
Now, there's only one issue left: Noise on the headset. As soon as the stream is enabled, you can hear noise on the headset (when audio is silent - if you listen to music, you can't hear it anymore).
The HS is dead silent on omap5-uevm when doing: aplay -Dplughw:1,0 -i -v -fdat /dev/zero
Can it be line another isolation issue?
I recall hearing the pixels on the display via the headphone in a prototype I have have worked in the past, but if I put music on, it just masked the noise.
However, there's something weird I did notice: Even on Headset volume 0 in AlsaMixer, audio is pretty loud! In fact, it's probably the maximum volume I would personally use.
On omap5-uevm with Headset Volume on 0 (0.00dB gain) it is fine, I would prefer a bit lower volume, but it is not loud by all means.
So something seems to increase the volume even though you set it to 0 in AlsaMixer.
I do wonder - is that some additional amplifier inside the TWL that is always switched on?
There is no more gain control in the HS path. We only have the Headset Driver.
Or why is the volume that loud?
That is a good question.
If that's the case, maybe the audio noise would be gone as well as soon as we switch that off.
Any ideas?
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> >
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Am Mittwoch, den 11.11.2020, 12:55 +0200 schrieb Peter Ujfalusi:
Hi,
Now, there's only one issue left: Noise on the headset. As soon as the stream is enabled, you can hear noise on the headset (when audio is silent - if you listen to music, you can't hear it anymore).
The HS is dead silent on omap5-uevm when doing: aplay -Dplughw:1,0 -i -v -fdat /dev/zero Can it be line another isolation issue? I recall hearing the pixels on the display via the headphone in a prototype I have have worked in the past, but if I put music on, it just masked the noise.
Dave tested it a bit more and he thinks it's the SD Card access you're hearing :)
But yeah, either it's pixels or the SD Card, but something seems to add noise to the headset port.
Hm, I'm not sure what Nikolaus changed here. AFAIK, he used the uEVM as reference - so if he copied the headset schematics from the uEVM, it should be pretty noiseproof. Though it isn't.
Or is MIPI the difference? Or traces too close together?
Anyways, that seems like something we can't fix. But yes, as soon as you have audio playing, you can't here it anymore.
Which makes me wonder: Does the TWL maybe have a compressor included that increases the volume if audio isn't playing - which would explain you hear the noise only when no audio is being played.
However, there's something weird I did notice: Even on Headset volume 0 in AlsaMixer, audio is pretty loud! In fact, it's probably the maximum volume I would personally use.
On omap5-uevm with Headset Volume on 0 (0.00dB gain) it is fine, I would prefer a bit lower volume, but it is not loud by all means.
Yes, that's what I mean :) But I expected it to be completely switched off on 0 :)
So something seems to increase the volume even though you set it to 0 in AlsaMixer. I do wonder - is that some additional amplifier inside the TWL that is always switched on?
There is no more gain control in the HS path. We only have the Headset Driver.
Or why is the volume that loud?
That is a good question.
Dave mentioned on IRC that this is probably how the TWL is designed. You basically set the maximum volume in the headset driver - and the true volume control will be done via software mixing (this is probably how most Android devices do that as well :))
If that's the case, maybe the audio noise would be gone as well as soon as we switch that off.
Any ideas?
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> >
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi,
On 11/11/2020 18.38, Michael Mrozek wrote:
Am Mittwoch, den 11.11.2020, 12:55 +0200 schrieb Peter Ujfalusi:
Hi,
Now, there's only one issue left: Noise on the headset. As soon as the stream is enabled, you can hear noise on the headset (when audio is silent - if you listen to music, you can't hear it anymore).
The HS is dead silent on omap5-uevm when doing: aplay -Dplughw:1,0 -i -v -fdat /dev/zero Can it be line another isolation issue? I recall hearing the pixels on the display via the headphone in a prototype I have have worked in the past, but if I put music on, it just masked the noise.
Dave tested it a bit more and he thinks it's the SD Card access you're hearing :)
Haha, cool audible storage device access LED :D
But yeah, either it's pixels or the SD Card, but something seems to add noise to the headset port.
Hm, I'm not sure what Nikolaus changed here. AFAIK, he used the uEVM as reference - so if he copied the headset schematics from the uEVM, it should be pretty noiseproof. Though it isn't.
Or is MIPI the difference? Or traces too close together?
Anyways, that seems like something we can't fix. But yes, as soon as you have audio playing, you can't here it anymore.
Which makes me wonder: Does the TWL maybe have a compressor included that increases the volume if audio isn't playing - which would explain you hear the noise only when no audio is being played.
The analog line receives load even when you play silence and the interference on the loaded lines might be audible. I think you should be able to see it with a scope. Just play /dev/null and do 'grep -R pyra /' at the same time.
I wonder how the noise will change after: amixer -c1 sset 'Headset Left Playback' 'Off' amixer -c1 sset 'Headset Right Playback' 'Off'
And what will the scope tell if you stop the /dev/null playback.
Phoenix might pull the analog lines down when the driver is turned off.
However, there's something weird I did notice: Even on Headset volume 0 in AlsaMixer, audio is pretty loud! In fact, it's probably the maximum volume I would personally use.
On omap5-uevm with Headset Volume on 0 (0.00dB gain) it is fine, I would prefer a bit lower volume, but it is not loud by all means.
Yes, that's what I mean :) But I expected it to be completely switched off on 0 :)
There is no real mute for the paths. I have added the DAC and driver as DAPM widgets as there is a certain sequence which needs to be followed to reduce the pop noise.
I think we could add dummy DAPM switch in a path to expose for muting/unmuting, but the gain control has no mute state.
So something seems to increase the volume even though you set it to 0 in AlsaMixer. I do wonder - is that some additional amplifier inside the TWL that is always switched on?
There is no more gain control in the HS path. We only have the Headset Driver.
Or why is the volume that loud?
That is a good question.
Dave mentioned on IRC that this is probably how the TWL is designed. You basically set the maximum volume in the headset driver - and the true volume control will be done via software mixing (this is probably how most Android devices do that as well :))
That might be true, but I think the Galaxy Nexus did used the HW gain controls as well as the SW. I can not recall. It had the AESS/ABE to play with the gains also...
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Am 31.07.2020 um 16:38 schrieb David Shah dave@ds0.me:
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
- My previous loopback experiment was not correct for some reason (I
think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
- I tried deliberately glitching the ABE_CLKS signal (from TWL to
OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint.
Interesting! This may help Peter to mimic the issue on the uEVM.
This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
Looks all very plausible now. Sampling the input data by an edge triggered flipflop in the moment the input swings from one data level to the other (this is where digital logic becomes an analog device) the bit value sampled makes it very dependent on noise on the input line or some pico seconds fluctuations of the sample point and this may even drive the flipflop into https://en.wikipedia.org/wiki/Metastability_(electronics)
So the sampling should take place while the data is stable. This is why inverting the clock polarity did work for the Pandora.
Unfortunately this doesn't help to find a good solution :(
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.
I have tried to better understand omap5 and twl6040 TRM but all I found was that it should magically synchronize through the clock feedback and simply work. No configuration registers.
On Thu, 2020-07-30 at 20:37 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 20:29 schrieb David Shah dave@ds0.me:
A tiny bit more insight.
It also seems possible to stop the glitching by disabling the _up_link channels on the OMAP side, either by clearing PDM_UP[1-3]_EN or setting SW_UP_RST in MCPDM_CTRL.
This actually seems slightly more reliable than disabling the loopback clock input buffer. But I suspect disabling that input buffer also breaks the uplink path, I haven't tried yet.
Disabling the uplink by disabling the uplink data input buffer, on the other hand, does not fix the glitching, so the glitching is not some strange result of the uplink data stream itself. Instead there must be some strange cross-connection between the up and down link in the OMAP5 that gets messed up by electrical noise (???). All the more mysterious...
That is certainly something to discuss with TI people (Peter Ujfalusi is still active - sent a mail a week ago about "omap-mcbsp 49022000.mcbsp: TX Buffer Overflow!").
As a worst case scenario, a patch that fully disabled the uplink channels when not being used would already improve reliability a lot. The mechanical noise of the vibra would make the internal microphone useless anyway.
Not necessarily since the mic has a sound guide and small hole on the left side of the keyboard. So it may be possible to hear the rumble but it would not make the recorded sound useless. It may even be possible to do noise cancelling for the vibra activities through aess (yes I know it is a dream)...
Best regards, Nikolaus
Best
David
On Thu, 2020-07-30 at 13:10 +0200, H. Nikolaus Schaller wrote:
Am 30.07.2020 um 13:02 schrieb David Shah dave@ds0.me:
On Thu, 2020-07-30 at 12:37 +0200, H. Nikolaus Schaller wrote:
Yes, I can confirm the effect.
After doing devmem2 0x4A0029A0 w 0x0080118 sound output stops (but aplay continues to run without notice about buffer under/overflow or alike). After restarting aplay sound is better. And vibra influence is no longer noticeable. Restoring devmem2 0x4A0029A0 w 0x1080118 makes problem come back
even while aplay runs. But still it depends on volume. So high volume + 0x1080118 is unreliable.
Hm. Is there a clock polarity setting? Either in McPDM or the twl6040? If clock polarity would be wrong, then it may depend on power supply noise if the data line is sampled correctly and the previous bit value creeps in or some random bit is read.
As far as I know there isn't one; the errata does suggest adding an external inverter to work around a clock phase issue (but I don't think that's exactly the same problem as what we see here.)
Ok, that could be the missing inverter I had hoped that it can be software controlled... Adding one in hardware would be more difficult than the missing capacitor :(
There are also the OMAP IO drive strength and slew settings to play with though.
Indeed. If the drive strengh is higher the slew rate is higher and the risk of sampling the wrong value should go down. Let's hope it goes this way...
BR, Nikolaus
> Am 30.07.2020 um 12:20 schrieb H. Nikolaus Schaller < > hns@goldelico.com>: > > Wow! > Maybe you can ask Peter Ujfalusi as he has done a lot of > previous > work for twl audio. > > I'll check all this as soon as I find time. > > BR and thanks, > Nikolaus > >> Am 30.07.2020 um 12:15 schrieb David Shah dave@ds0.me: >> >> Well, I seem to have found a solution. It is totally and >> utterly >> inexplicable, but there you go. >> >> The OMAP5 TRM says that the input buffer for MCPDM_LB_CLK >> - >> the >> clock >> going out from the OMAP5 to the TWL, that clocks the PDM >> stream >> and >> mirrors the TWL clock output - must be enabled; as the >> input >> signal is >> used internally for retiming purposes. >> >> But using devmem2 to DISABLE this input buffer, against >> the >> TRM >> advice, >> seems to fix the stream desynchronisation issue! >> >> # devmem2 0x4A0029A0 w 0x0080118 >> >> There is still a quiet a crackle when the vibra turns on >> or >> off, >> which >> really does seem like switching noise from the motor, but >> the >> stream is >> never actually corrupted and the crackle does not disrupt >> what is >> playing! >> >> I'm done with OMAP stuff for today :) but I'll experiment >> more >> over the >> weekend. If you get a chance, I would be interested to >> see if >> this is >> reproducible on your unit, too. >> >> I need to think a bit more about how this could actually >> look >> from a >> silicon point of view to see if there is a better fix. It >> is >> possible >> that disabling the input buffer means that the OMAP5 is >> using >> some >> internal clock instead that isn't disrupted by noise on >> the >> pad. >> >> It could also be related to OAMP5 errata i800 / TWL >> errata 6, >> which >> involves relative clock phases. I had ruled that out >> because >> it >> would >> be odd for power supply noise to affect that; and it >> reads >> more >> like >> dropped/duplicated samples than total loss of stream. >> >> Best >> >> David >> >> >> On Wed, 2020-07-29 at 18:32 +0100, David Shah wrote: >>> Hi Nikolaus, >>> >>> Couple of thoughts below. >>> >>> On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus Schaller >>> wrote: >>>>> Am 29.07.2020 um 18:58 schrieb H. Nikolaus Schaller >>>>> < >>>>> hns@goldelico.com>: >>>>> >>>>> >>>>>> Am 29.07.2020 um 18:04 schrieb David Shah < >>>>>> dave@ds0.me>: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried adding a 470nF 0402 capacitor in what I >>>>>> hope >>>>>> was >>>>>> the >>>>>> right >>>>>> place (see attached), >>>>> >>>>> yes, from a first glance it looks to be right! >>>>> >>>>>> and replacing the associated resistor with a >>>>>> short. Sadly that made no difference, but maybe >>>>>> 470n >>>>>> isn't high >>>>>> enough >>>>>> (I also have 4.7u 0805 but I suspect that might >>>>>> be >>>>>> too >>>>>> tall. >>>>> >>>>> Hm. I hope I find some minutes to open my sample >>>>> and >>>>> try >>>>> the >>>>> same. >>>>> Then we know. >>>> >>>> Here is a full picture where I tried tp mimic the >>>> colours: >>>> >>> >>> Yes, that matches what I did. >>> >>>> Maybe the copper trace between the C and the R is too >>>> small. >>>> So a >>>> wire directly >>>> across all three solder pads could be better. Or >>>> scratching >>>> off the >>>> solder mask from >>>> the ground plane around and soldering the capacitor >>>> directly >>>> to >>>> GND. >>>> >>> >>> In my second attempt with 4.7u, I did effectively end >>> up >>> with >>> one >>> solder blob all the way across that should be pretty >>> low >>> impedance. >>> >>>> If I find time (which is unfortunately unlikely) I >>>> could >>>> add >>>> two >>>> wires to the pads of the >>>> capacitor and get them outside the Pyra to be able to >>>> measure >>>> the >>>> voltage with the oscilloscope. >>>> >>>> Some thoughts about the software side: I remember >>>> that >>>> Peter >>>> Ujfalusi >>>> long time ago mentioned >>>> different clocks. Maybe the 32kHz clock or the McPDM >>>> clock >>>> which >>>> could be used as a >>>> reference. And there was a kernel version where sound >>>> became >>>> a >>>> little >>>> better (but I wouldn't >>>> bet for it). So there may still be another effect in >>>> software. >>>> Maybe >>>> in addition so that >>>> what we observe is the sum of several effects. >>>> >>> >>> Interesting, the clocking definitely isn't quite right >>> in >>> the >>> latest >>> as >>> high power mode also used to work on 4.19 but doesn't >>> seem >>> to >>> any >>> more. >>> >>>> One question about the loopback: does it show if the >>>> PCM >>>> data >>>> is >>>> coming in the right >>>> and stable timing? E.g. speed may fluctuate but still >>>> provide >>>> perfect >>>> data mirroring. >>>> Nevertheless, fluctuating speed may become audible. >>>> >>> >>> This is true, there is some possibility for "common >>> mode >>> failure" >>> that >>> would symmetrically affect both directions. >>> >>>> But it is difficult to see how this would be >>>> influenced >>>> by >>>> the >>>> Vibra. >>>> Well, the Vibra >>>> is also controlled through some PCM channel because >>>> the >>>> motor >>>> can >>>> "play" the bass sound... >>>> >>> The Vibra seems to be set to "Input FF" mode by default >>> AIUI it >>> is >>> controlled by I2C not the PDM stream when using >>> vibra.py. >>> But >>> you can >>> set it to PDM mode in alsamixer which seems to turn it >>> always >>> on >>> (presumably a 1 is sent in the PDM stream for that >>> channel >>> by >>> default?) >>> noise that always goes away as soon as you turn it off >>> again >>> rather >>> than glitching the stream. >>> >>> It also seems to differ significantly less depending on >>> the >>> volume >>> setting - it isn't directly scaled by volume in the >>> same >>> way as >>> Vibra >>> Right glitching is; as if it is affecting something >>> later >>> in >>> the >>> signal >>> path. >>> >>> Strange that an unconnected channel also makes a >>> difference, >>> but the >>> H- >>> bridge is still presumably still switching and any H- >>> bridge >>> does >>> produce some shoot-through noise. >>> >>> I am wondering now if some config issue is making the >>> TWL >>> much >>> more >>> sensitive than it should be for some reason. >>> >>> Best >>> >>> David >>> >>>>>> I'm still proud to own the first modded Pyra, >>>>>> even >>>>>> though >>>>>> it >>>>>> didn't >>>>>> work :D >>>>> >>>>> ++ >>>>> >>>>> BR, Nikolaus >>>>> >>>>>> Best >>>>>> >>>>>> David >>>>>> >>>>>> On Wed, 2020-07-29 at 17:37 +0200, Michael Mrozek >>>>>> wrote: >>>>>>> Am Mittwoch, den 29.07.2020, 17:25 +0200 >>>>>>> schrieb H. >>>>>>> Nikolaus >>>>>>> Schaller: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Oh, that's good news! >>>>>>> Can you let me know where to solder them so >>>>>>> I'll >>>>>>> try >>>>>>> that >>>>>>> here? >>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Well, we tested various materials between the >>>>>>> CPU >>>>>>> board >>>>>>> and >>>>>>> the >>>>>>> plastics - but >>>>>>> the best solution is to put NOTHING in between. >>>>>>> >>>>>>> If we put a metal sheet in there, the heat goes >>>>>>> into >>>>>>> the >>>>>>> metal >>>>>>> and >>>>>>> heats the >>>>>>> battery - whereas almost nothing moves into the >>>>>>> heatsink >>>>>>> (where >>>>>>> it >>>>>>> should). >>>>>>> >>>>>>> So there's a gap of 0.4mm between the CPU board >>>>>>> and >>>>>>> the >>>>>>> backside, and >>>>>>> as the >>>>>>> keymat acts a bit like a cushion as well, I >>>>>>> guess a >>>>>>> small >>>>>>> part >>>>>>> like a >>>>>>> capacitor >>>>>>> could even use up to 0.6 to 0.7mm. >>>>>>> >>>>>>> So there should be enough space to put a small >>>>>>> capacitor in >>>>>>> there. >>>>>>> >>>>>>>> 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). >>>>>>> >>>>>>> We have 500 already-produced PCBs - so I guess >>>>>>> we'd >>>>>>> need to >>>>>>> fix >>>>>>> these >>>>>>> manually. >>>>>>> But hey, MWeston had to replace 500 capacitors >>>>>>> on >>>>>>> the >>>>>>> Pandora >>>>>>> PCBs >>>>>>> manually as >>>>>>> well. >>>>>>> >>>>>>> Only bigger downside would be that we have >>>>>>> another >>>>>>> setup >>>>>>> costs >>>>>>> for >>>>>>> the next CPU >>>>>>> boards... that's around 5000 EUR alltogether :/ >>>>>>> >>>>>>> >>>>>> <photo_2020-07-29_17-03-18.jpg> >>>>> >>>>> _______________________________________________ >>>>> Kernel mailing list >>>>> Kernel@pyra-handheld.com >>>>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >>> >>> _______________________________________________ >>> Kernel mailing list >>> Kernel@pyra-handheld.com >>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel