Funny, distorted characters on Serial debug output from ATtiny 1614 [SOLVED]

Posting this in hope it might help someone else.

I am working with a new-to-me microcontroller: ATtiny 1614, using DrAzzy's megaTonyCore.

I got the blink sketch going, and the LED worked fine. But the serial output was weird. Characters appearing in sync with the blinking LED. Approx same number of characters as expected. But most of the characters were high-order ASCII graphical characters. A few characters came out ok: 'e', 'f', etc. I explored the obvious:

  1. Baud rate mismatch: No
  2. Different start bits, stop bits, parity, etc: No
  3. Wiring problem: No
  4. Linux tty definition: No

I eventually realised I had underclocked the processor from 20MHz to 1MHz. Clocked back up 20MHz. All good!

Almost certainly a serial Baud rate error, rather than a clock frequency problem. The MCU is spec'd to run at 32 kHz and lower.

Almost certainly a serial Baud rate error, rather than a clock frequency problem. The MCU is spec'd to run at 32 kHz and lower.

I assure you it wasn't a serial baud rate mismatch. Evidence:

  • There was a 1:1 ratio of characters sent and characters received.
  • I observed the bit patterns on a scope to verify baud rate.
  • Some characters were received correctly, and there seemed to be a relationship between bit pattern and success
  • I changed clock frequency without changing serial baud rate either in the sketch or in the monitoring terminal, and the serial output immediately corrected. I changed in back again and it immediately failed in the same way.

I spent best part of a day tracking this down in great detail. It's a little disappointing to be told my conclusions are wrong. The MCU might work to 32KHz but it doesn't mean all aspects of peripherals and Arduino core continue to work at that speed.

I assure you it wasn't a serial baud rate mismatch

I'm not assured. Serial baud rates must match to within about 1% or better.

If the Baud rate is off by more than that, you get the symptoms you observe: bit changes, parity errors, etc. That often happens, for example, when using the internal RC oscillator as the MCU clock, rather than a crystal, and sometimes, with a low quality or inaccurate crystal.

All aspects of the microprocessor work as described in the data sheet, down to a clock rate of 32 kHz and below. However, the serial Baud rates are accurate only for certain clock rates and choice of USART bit rate divisor.

Tables 24-5 and 24-6 of the ATtiny1614 data sheet provide some details about the acceptable error rates.

As it happens, megaTinyCore calculates baud rate slightly wrong - the calibration error values meant for this purpose were applied incorrectly. Didnt usually become "clinically relevant", but sometimes did (that's how I found out about it). This will be fixed in 1.1.3, which should be released within the week.

In other words, a Baud rate mismatch.

In other words, a Baud rate mismatch.

Sorry I misunderstood you, I thought you meant the two ends were set to two different baud rates. I can see how a fractional difference in baud rate would account for this. Perhaps compounded by the calculation error DrAzzy mentioned.