Re: Bug #1024 (oscillating re-camping), the story goes on...
I suggest to stop the other 2 32kHz oscillators on mainboard to rule out mechanical (as well as electrical / EM) interference between them and the calypso oscillator. Can be done by simply shorting/grounding the crystals, or maybe even with config-register settings (not yet checked). Ping me on freenode #openmoko-cdevel DocScrutinizer if you need help on that. If there's a clockmaker out there, it would be great to test the one remaining 32kHz crystal by using the sophisticated acoustical test equipment for wrist watches clock. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Dieter Spaar wrote: Here in my lab environment I can simulate the serving cell that is used in the trace. However with my few GTA02 devices I don't observe bug #1024 and even in Deep Sleep mode the TOA values are stable. By the way, Joerg has proposed another interesting approach: if the oscillator's drive strength is insufficient, we should be able to make things worse by reducing it, which you mentioned could be done by the firmware. Is there anything else that's driven by the 32768 Hz clock that we can access, e.g., a RTC or some counter ? If yes, we could use that to check if the clock has significant variations. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Hello Werner, Werner Almesberger wrote: By the way, Joerg has proposed another interesting approach: if the oscillator's drive strength is insufficient, we should be able to make things worse by reducing it, which you mentioned could be done by the firmware. Very good idea, I can check that out and see if I get different results. Is there anything else that's driven by the 32768 Hz clock that we can access, e.g., a RTC or some counter ? If yes, we could use that to check if the clock has significant variations. Not something I am aware of. I think the 32kHz oscillator drives a RTC if the Calypso chip set alone is used for a simple phone. Best regards, Dieter ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Am Mo 30. März 2009 schrieb Werner Almesberger: Dieter Spaar wrote: Here in my lab environment I can simulate the serving cell that is used in the trace. However with my few GTA02 devices I don't observe bug #1024 and even in Deep Sleep mode the TOA values are stable. By the way, Joerg has proposed another interesting approach: if the oscillator's drive strength is insufficient, we should be able to make things worse by reducing it, which you mentioned could be done by the firmware. Dieter, maybe we could have a debug-version of moko11 to implement a service AT command to tweak those config registers. This way we could ask users who actually can reproduce #1024 to check if there's any difference when issuing this power tweaking back and forth. Is there anything else that's driven by the 32768 Hz clock that we can access, e.g., a RTC or some counter ? If yes, we could use that to check if the clock has significant variations. Werner, a brilliant point. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Am Mo 30. März 2009 schrieb Dieter Spaar: Hello Werner, Werner Almesberger wrote: By the way, Joerg has proposed another interesting approach: if the oscillator's drive strength is insufficient, we should be able to make things worse by reducing it, which you mentioned could be done by the firmware. Very good idea, I can check that out and see if I get different results. Is there anything else that's driven by the 32768 Hz clock that we can access, e.g., a RTC or some counter ? If yes, we could use that to check if the clock has significant variations. Not something I am aware of. I think the 32kHz oscillator drives a RTC if the Calypso chip set alone is used for a simple phone. Hmm this sounds like there actually *is* sth we can use for this purpose. Is it (the RTC) disabled by default on OM's version of FW, or what's the issue with it? Or is this RTC an external component that's just clocked by calypso's 32kHz. Still it would be interesting to enable such an external clock as it maybe would stop the constant disabling/enabling of calypso's 32kHz clock generator. /j signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Hello Joerg, Joerg Reisenweber wrote: Hmm this sounds like there actually *is* sth we can use for this purpose. Is it (the RTC) disabled by default on OM's version of FW, or what's the issue with it? Or is this RTC an external component that's just clocked by calypso's 32kHz. Still it would be interesting to enable such an external clock as it maybe would stop the constant disabling/enabling of calypso's 32kHz clock generator. I will check if there is anything which could be used. Its not that easy because we don't have all the source code which is evolved. Additionally I am not sure if a RTC is driven by the 32KHz oscillator only. It could be done similar to how it is done now, if the Calypso sleeps, the 32kHz oscillator is used, otherwise the main oscillator. The accuracy requirements for GSM are rather strict, so even without the 32 kHz oscillator the running system surely can handle the timing for a RTC. Best regards, Dieter ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Dieter Spaar wrote: Additionally I am not sure if a RTC is driven by the 32KHz oscillator only. I guess that's okay. As long as the 32 kHz clock is driving the RTC and whatever is causing #1024 at the same time, then any clock upset on one side will show up on the other as well. This would allow us to detect a clock running too slow or too fast on average. It wouldn't help with a clock that varies but has the correct average frequency. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
Am Mo 30. März 2009 schrieb Dieter Spaar: Hello Joerg, Joerg Reisenweber wrote: Dieter, maybe we could have a debug-version of moko11 to implement a service AT command to tweak those config registers. This way we could ask users who actually can reproduce #1024 to check if there's any difference when issuing this power tweaking back and forth. This should be possible without too much effort. However we can probably only make it worse (less current), the oscillator current should be at the highest possible value in our firmware. That's ok. This is the idea of all this tweaking anyway. If it gets worse with lower power but doesn't break completely then we are rather sure it's caused by 32k-osc. BTW sometimes osc run even more stable on lower power driving the crystal ;-) /j signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 (oscillating re-camping), the story goes on...
On Monday 30 March 2009, Joerg Reisenweber wrote: Am Mo 30. März 2009 schrieb Joerg Reisenweber: I suggest to stop the other 2 32kHz oscillators on mainboard to rule out mechanical (as well as electrical / EM) interference between them and the calypso oscillator. Also all users testing for #1024 should make sure about whether WLAN/BT is enabled or off while the bug actually happens. If enabled, please switch off and see whether sth is changing wrt #1024. Both BT and WLAN were nominally off when I collected the logs, but that was with FSO MS4.1 which had a 2.6.24 kernel. I think we only got the ability to turn the WLAN off entirely with 2.6.28 didn't we? ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
