[OpenTRV-dev] Puzzling long-term bugs

[Deniz Erbilgin]

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).
http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf

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.

Regards,

Deniz

On Thu, Sep 29, 2016 at 9:39 AM, Kevin Wood <kevin at the-wood-family.com>
wrote:

> 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
>
>
> Kevin
>
> > 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
> the
> > 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
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20160929/89cdc9f7/attachment.html>