[OpenTRV-dev] Puzzling long-term bugs

[Adrian Godwin]

Could you measure the PC's baud rate at the AVR and then adjust the BRG
divider (or the AVR's clock calibration, if that's possible) to match ?


On Thu, Sep 29, 2016 at 10:39 AM, Deniz Erbilgin <deniz.erbilgin at gmail.com>
wrote:

> 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
>>
>
>
> _______________________________________________
> 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/0a0b8958/attachment.html>