[OpenTRV-dev] Puzzling long-term bugs
deniz.erbilgin at gmail.com
Thu Sep 29 10:39:58 BST 2016
Hmm. Reading through the docs, it seems that the internal oscillator is
factory calibrated to within 10% (p304, table 29-9).
The datasheet also claims that for 8 bit UART the max error the receiver
can tolerate is about 4.5% (p185, table 20-2).
We did try comparing the internal clock against the on board watch crystal
to try and catch anything wildly off, but I'll check any duds I come across
with a frequency tester.
On Thu, Sep 29, 2016 at 9:39 AM, Kevin Wood <kevin at the-wood-family.com>
> Hi Damon,
> If it's the RC oscillator then it will be far enough out to cause issues
> on long blocks of data in my experience.
> I'm not sure why this is a problem. As you say, it SHOULD be possible for
> the receiving UART to resync on every start bit, or, in fact, on every
> transition of the signal. The fact is that they don't appear to do so
> except on a start bit after the link has fallen idle, or, at least, the
> typical PC COM port or USB-to-Serial adaptor doesn't.
> Maybe the AVR's UART is more intelligent in this respect, and this is why
> we are not seeing corruption on firmware loads, since it's then the PC
> that is transmitting flat-out?
> Best Regards
> > Hi,
> > The UART clocks being out relative to one another is in my view quite
> > likely an issue since on our boardâ€™s side the clock is derived from the
> > AVRâ€™s 8MHz internal RC clock.
> > This does mainly seem to be an issue with solid blocks of characters (eg
> > ~16 or more bytes) being sent at once (to the AVR board), though I would
> > expect everything to resync on each start bit.
> > I donâ€™t believe any buffers are being overwritten since we are using
> > normal Arduino queued serial byte streams, with everything interrupt
> > driven, though that may be worth another look, thank you.
> > Puzzling!
> > Rgds
> > Damon
> >> On 28 Sep 2016, at 17:11, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> >> Is this more than just UART being UART and the clocks of of each side
> >> being out?
> >> Maybe try repeatedly sending 'U' on one of the problematic devices and
> >> measure the frequency, should be half the baud rate as U is 01010101
> >> IIRC you use a relatively slow baud rate (4800 IIRC) so you could be
> >> overwriting data in a buffer if you send data to fast?
> >> Jeremy
> >> On 28 Sep 2016 3:08 p.m., "Damon Hart-Davis" <damon at opentrv.uk> wrote:
> >> Hi,
> >> We have a Wiki page here for our general amusement:
> >> https://github.com/opentrv/OTWiki/wiki/Puzzling-Long-Term-Bugs
> >> Weâ€™ve certainly been having some puzzlement while putting together a
> >> small run of valves for a trial over the last few days. Could be
> >> summarised as â€˜dodgy serialâ€™:
> >> - Some REV7 and other V0p2 units seem to have problems with serial RX
> >> and TX, garbling some characters
> >> - Seems especially problematic for longer (16+?) blocks of
> >> characters such as setting a key
> >> - Have tried to ensure no sleeping or other fiddling with CPU clock
> >> during UART operation
> >> - Seems to apply to a few % of REV7, REV10 boards at least
> >> - It has been possible to load a large (30KB) app over serial with
> >> the bootloader.
> >> Any ideas welcome!
> >> Rgds
> >> Damon
> >> _______________________________________________
> >> OpenTRV-dev mailing list
> >> OpenTRV-dev at lists.opentrv.org.uk
> >> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenTRV-dev