Just a quick heads up


OMAP+TWL6040 use a protocol called McPDM but it is similar to SPI and I2S. Unfortunately we have not found any registers for inverting the clock out pin... If you are interested in the details, it is twl6040 erratum #8 "PDM Downlink Data Corrupted" in TI document SWCZ0007D from 2011 (it seems to be NDA only).

I couldn't find any technical reference manual for the OMAP 5, but if a Sitara am572x is close enough, I might have a solution. In the Sitara manual:
there is a paragraph about the Audio Interface called McASP in this case that references to the Paragraph 18.4.6.1 Pad configuration. There you have several registers setting the IO timing (Virtual timing mode) as well as the pull strength of the corresponding pin.
If you check out 18.4.6.1 and following there is a detailed description about calibration of IO timing. As the Pad configuration seems to be function independent and functional for each individual pin, this might be a solution if existent on the OMAP.
They also state that this IO timing recalibration should be done on every core domain voltage change, if I understood correctly.

None technical people have been warned, the document has 8000 Pages :p.
 
Sounds like a lot of speculation. Has any actual measurements been done? I understand that the actual clock signal is tricky to measure, but what about the power line (close to the twl6040) while the vibrator is running? If that's a problem, maybe it can be helped with better filtering or additional capacitors. Does the problem get worse at lower battery levels?

Maybe I should ask all these questions on the mailing list, and leave this thread for grammar discussions? xD

It is difficult to measure indeed. Even with an active probe you would probably add 1pF which could change the signal to much and don't forget that your probe is high impedance and acts as a stub that injects reflections back into the clockline and therefore changes the timing. It's probably better to simulate/calculate this but for this in order to work, we would need to know how much phase reserve the TWL actually has. This could probably be enhanced further if the stub were the resistor was removed would be properly tuned (if possible). I don't know the layout, but with the right termination you can inject pretty much anything (depending on the clock frequency shorting the stub for pure reflection is not an option). It would probably be enough to terminate the stub with the characteristic wave impedance (Wellenwiderstand) to inhibit any disturbances, but this I cannot say without further knowledge of the design.

If any measurements are necessary, I have equipment up to about 200MHz and an active FET probe, but I'm pretty sure hsn has the same and I'm sure we would measure a lot of garbage and need a lot of time to interpret the measurements (again, depending on the clock frequency).

BTW whats the clock frequency of the TWL?
 
  • Like
Reactions: rSl
Even my Pandora would struggle to remain from the charger for that long, but would maybe just about manage it (though it'd be in desperate need of a charge when you next plug it in).

That's weird. My Pandora "turned off," which it never fully turns off as we know, can last months
 
Really? I'm pretty sure running poweroff on it actually does cut the power from the CPU and everything else. I'm not sure how it could last months if not. And if you can never turn it off then reportedly it'd never be safe to insert the battery?!?
 
I just meant like a ps vita or switch where you could pick up after hibernation and resume a game quickly after an hour or day or whatever.
 
Really? I'm pretty sure running poweroff on it actually does cut the power from the CPU and everything else. I'm not sure how it could last months if not. And if you can never turn it off then reportedly it'd never be safe to insert the battery?!?

Yep part of the Pandorais always on and it can be woken up from shutdown. Here is an example post of that.

 
Okay, that part of the system is known as the charge chip which contains the RTC. On any computer since the 1990s I'd expect the RTC to run off battery power even during a power cut, although I am aware that my old xbox used a capacitor for this job. The only tricksy bit about that is that it's able to bring the system back up, and according to Wizardstan that needs a compile change to the kernel, which suggests the kernel is running, but that could just be an entry point to bring the kernel back from an power up due to an RTC event. I couldn't say.

But if the CPU and RAM are running and taking a few mW from the battery via the charge chip, I can't understand why it's safe to reinsert the battery after removing it only when the system is nominally 'off'. But eh, well it works for me so I guess it doesn't really matter.
 
The only tricksy bit about that is that it's able to bring the system back up, and according to Wizardstan that needs a compile change to the kernel, which suggests the kernel is running, but that could just be an entry point to bring the kernel back from an power up due to an RTC event. I couldn't say.
No idea how the pandora works. Could be as you say, but it could also be that the kernel needs to be modified in order to be able, before poweroff, to command the charge chip to wake the CPU/system at the desired time. Once the charge chip wakes the system and the bootloader runs the kernel, the kernel might not need any further modification to boot (or maybe one modification to know why it is booting or so, but not so necessary).

I don't think the kernel would be running if the charge chip is powered on but the CPU powered off. If the kernel was running in the charge chip, that would be like a BMC or so, and they're normally used in servers, not in small devices, but what do I know?
 
Last edited:
Kernels (at least the linux kernel which is normally what I'm referring to when I speak of them) run on CPUs. They might also be running on various cores dotted about the system, but I'm only really considering the main system core that you're actually talking to when you spawn a game process or a window or what have you.
 
The only tricksy bit about that is that it's able to bring the system back up, and according to Wizardstan that needs a compile change to the kernel, which suggests the kernel is running

IMO kernel running = not off

But eh, well it works for me so I guess it doesn't really matter.

Agreed
 
I am aware that my old xbox used a capacitor for this job.


Of which you should remove, if you want to keep your xbox. If you have a v1.5 or lower xbox, they pop and leak on the mobo. Not an if it will pop, but a when.

A simple heat and pull. The xbox will work fine without one.

Sent from my H3123 using Tapatalk
 
I don't know. I'd say it is not possible yet, it might be in the future (with hibernation), but I'm not convinced that it would be possible now (without hibernation) even if the OMAP5432 didn't have the bug in idle mode.
I don't know if idle mode or even suspend would be enough to keep the system powered for 2 days. If we ever get hibernate and resume to work, you'll be able to do that even with the idle bug.

I'm not terribly worried about the idle bug. With the sea of disposable smart devices out there, it can be easy to forget about one of the more unique features (and one not to be overlooked), the upgradable CPU board. So one way or another, what we see today will be a lot better later on. Unlike with phones and tablets, we wont be stuck with the same SoC and have wait for a whole new device to come out.
 
I'm not terribly worried about the idle bug. With the sea of disposable smart devices out there, it can be easy to forget about one of the more unique features (and one not to be overlooked), the upgradable CPU board. So one way or another, what we see today will be a lot better later on. Unlike with phones and tablets, we wont be stuck with the same SoC and have wait for a whole new device to come out.
I'm not too concerned either. User replaceable battery and the fact that portable battery packs are easy to come by these days.
 
Back
Top