Serial buffer issue Attiny806 at 20MHz

[Rollpopptery]

There seems to be a problem with Serial specifically with Attiny806 at 20 MHz.
I have tested with the following combinations:
Multiple Attiny806 Micros.
Multiple Attiny1606 Micros.
CPU Clocks 10MHz, 16MHz, 20MHz
Baud rates 115200, 9600

The test code is simple, below.
At various combinations of baud rate , CPU clock, and micro, the characters are received and buffered correctly by Serial

with the exception of Attiny806 at 20MHz;
With the Attiny806 at 20MHz, at any baud rate, only the first 1 or 2 characters are received and buffered correctly:

//CODE
// This code echos back received characters from the buffer, at a rate of one character per second.
// Characters can be received quickly of course, they are stored in the receive buffer.
// That's what we are testing..
// the receive buffer.

void setup() {

Serial.begin(9600);

}

void loop() {

char inchar = Serial.read();

if(inchar > -1)
{
Serial.println(inchar);
}

delay(1000);

}

[hmeijdam]

I can't reproduce your issue.

I tested on a 806 with IDE 1.8.13 with Github version of MegaTinycore and IDE 1.8.19 with latest boards manager version of MegaTinycore
I use HTerm 0.8.5 as terminal prog

Both can receive 16 characters on 20, 10 or 8 MHz (the ones I tested)

Here are my settings

[SpenceKonde]

Hm. I'm pretty sure I don't have an 806 within reach.

The problem as described makes just about zero sense - there is no difference between the code running on an 806 vs any other part, and that it's only seen to fail at 20 MHz on impacted parts.

Can you please post what you're sending it and what the data output looks like? Since it seems that all the likely sort of problems have been ruled out, we're down to trying to squint at the console output like a fortune teller peering into a cup of tea looking for prophecies....

This modification should give more insight - with an LED and it's series resistor (connected correctly (you're holding the wire 0.3" away from the vcc pin, so you can touch the end of the wire to that and the light had better come on,

Once you have an LED on it, something you can do that would be useful is something like

void setup() {
  //delay(100); // If this never turns off the light, uncomment this and see if it ever turns it on, or if all delay()s are infinite.
  // I know it's not in the current release, but there was a bug like this at one point not *that* long ago as I seem to recall. 
  pinModeFast(PIN_PA7,OUTPUT); // The Fast versions are doing less shit in the background, and so I trust them more. 
  digitalWriteFast(PIN_PA7, HIGH); // they're also very easy to spot in asm listings. 
  delay(500);
  digitalWriteFast(PIN_PA7, LOW); // Quick flash on startup - make sure it's actually starting,
  Serial.begin(9600);   // And - that it's not restarting. 
}
void loop() {
  char inchar = Serial.read();
  if(inchar != -1) {
    Serial.println(inchar);
  }
  delay(1000);
}

This corrects the test (as I discuss below) and makes it flash an LED on PA7, though you could use any pin.

As written, your code would be guaranteed to break for half of the characters you could send it..... if(inchar > -1) means don't retain any characters with the high bit set. Even if you eventually plan to use a filter like that, you don't want it in the way now, because it could be covering up big clues. Most characters with the high bit set are not meaningful characters and usually don't display a proper glyph, but they give you one of those boxes, which is enough to tell you that you got a bad character. But in any event for debugging, gibberish characters are frequently valuable - if you're seeing them, that says "baud rate mismatch".

Other things I'd suggest include:
Verify that you have the decoupling cap installed and it is indeed properly soldered - with no method to see if the sketch has started and hence no way to know that it's restarting, and hence if you have some issue causing frequent resets (like a missing decoupling cap), you might not immediately notice it. This is something I would be particularly suspicious of if the above test showed lots of resets happening.
What voltage is it running at? You're not using it outside it's rated voltage range or anything right? (though AVRs are and always have been spec'ed conservatively) (3.3V at 20 MHz is not in spec, though IIRC they typically do work), It should be running at 5v if clocked at 20.

And you were using latest released version?

[Rollpopptery]

Thank you guys for taking the time to check this out.
I have used Dr Azzy test code un-modified, because my hardware has a LED on PA7. There is no problem with startup, led flashes.

Issue is still present on Attiny806 at 20MHz
To Test: Serial string "hello" is sent as a block with no delay between characters, ie
With arduino serial monitor see below , or an application python

I am using 1.8.19 arduino ide as per hmiedjam.
Latest mega tiny core libraries.

Because I have identical hardware that can take Attiny1606 or Attiny806.
I notice the issue is present only on Attiny806 at 20MHz. other CPU clock rates no problem, Attiny1606 no problem

The Arduino with settings:

The problem attiny806 at 20MHz 5volts:

Works fine on attiny1606 at 20Mhz

#A python program that also reveals the problem, because sends a string

import time
import serial

ser = serial.Serial(port="COM90", baudrate=9600, bytesize=8, timeout=2, stopbits=serial.STOPBITS_ONE)

ser.write(b'hello')

while (1==1):

if ser.in_waiting > 0:
    instring = ser.read()

    try:
        print(instring.decode("Ascii"))
    except:
        pass

[SpenceKonde]

AAHA!
That serial output was exactly the thing I had a sneaking suspicion would be seen. There's a clock mismatch, so when you send multiple characters in a row with only one stop bit, it gets confused because the sender is sending the next character, the receiver thinks it's on the tail end of the stop bit, and within a few bytes, it's gotten far enough off that it's more than half a bitperiod off and seeing the wrong characters.

So, it's not specific to the 806, it's specific to THAT 806 in combination with THAT serial adapter, when running at that voltage I think the tiny is running a hair slow, and the serial adapter a hair fast. Either nudge the oscillator cal up a notch or two, or set the thing talking to it to use 2 stop bits, (this is precisely why >1 stopbit options exist :-P ). The extra stop bit adds enough time between the bytes that the receiver will for sure have finished receiving (the stopbit setting only effects TX behavior, not RX behavior - you likely don't need to set this on the tinyAVR)

Also, the Arduino IDE serial console is unfit for purpose. It is, without exaggeration, the worst serial console I've ever used. They have carefully avoided checking any boxes on my feature wishlist, from basic to advanced.

hTerm is the one you want. The person who did it comes from embedded software background, so it's got all those wacky features that we need.

[Rollpopptery]

Thanks for this, I will suspect that the Oscillator is a bit inaccurate at 20MHz, and avoid using it, unless I tune it..

But, just to haunt my sleep
I have found that SoftwareSerial is perfectly reliable at all baud rates up to 74880

Only Serial exhibits the issue, ( at all baud rates)

I have put the simple test code below for reference, it has the two versions, one uses SoftwareSerial, one uses Serial.

Possibly Serial, using the native UART, is more susceptible to clock inaccuracies , or less robust for whatever reason,
I am concluding that SoftwareSerial is more forgiving and reliable in general.

Summary:
All of my ATiny806 @ 20MHz :
Serial does not receive reliably at any baud rate.
However SoftwareSerial no problem for all baud rates (up to the capability of SoftwareSerial)

Baud rates tested: 300, 2400, 4800, 9600, 19200, 38400, 57600, 74880, 115200.

//CODE

// 16-Mar-2023
//
//----------------------------------------------------
// Attiny806 at 20MHz:
// Using SoftSerial this works for all baud rates to 74880
//----------------------------------------------------

#include <SoftwareSerial.h>

#define RXPIN (6)
#define TXPIN (7)

SoftwareSerial soft = SoftwareSerial(RXPIN, TXPIN);

void setup() {

soft.begin(9600);
}
void loop() {
char inchar = soft.read();
if(inchar != -1) {
soft.println(inchar);
}
delay(1000);
}

/*

//--------------------------------------------------------------------------------------------
// Attiny806 at 20MHz:
// Using Serial, this does not work reliably for any baud rates
//--------------------------------------------------------------------------------------------

void setup() {

Serial.begin(9600);

}
void loop() {
char inchar = Serial.read();
if(inchar != -1) {
Serial.println(inchar);
}
delay(1000);
}

*/

[Rollpopptery]

Thanks
Conclusion; 20MHz oscillator running slightly slow as Dr said. I have tested USART0 using native avr serial port library
and saw same issue. Tweaking down F_CPU value to 19000000 ( to adjust baud rate calculation) makes problem go away.

// tweaked this down to fix errors at 20MHz
//
#define F_CPU 19000000

#define USART0_BAUD_RATE(BAUD_RATE) ((float)(F_CPU * 64 / (16 *(float)BAUD_RATE)) + 0.5)

[hmeijdam]

Did you see the page about self tuning?

[SpenceKonde]

He can't self tune, he's zero-series. Their event system was gutted, they can't get the required RTC output onto an event channel - PIT events are one one of the channels that the 0-series parts didn't get.

Though the tuning was largely meant for people who want to run their parts at funky speeds, if just trying to get the part to work at 20 MHz you could use a much more brute force approach (I'm assuming you don't have a scope - if you do, just output 1kHz PWM, view it on the scope (where you'll find it's not 1 kHz, and keep increasing the value passed to something like this; otherwise you can guess any check with this function and your application

bool tweakCal(int8_t tweakval) {
  volatile uint8_t* calptr=(volatile uint8_t*) (uint16_t)&SIGROW; /*points to start of sigrow */
  calptr +=26; /* now points to the location of the value loaded to to the oscillator at 20 MHz derived speeds (address determined experimentally) */
  uint8_t tweakedval = *calptr + tweakval; 
  uint8_t oldsreg = SREG;
  cli();
  if (tweakedval < 64) {
     __PROTECTED_WRITE(OSC20MCALIBA, tweakedval); 
    _NOP(); //don't have anything other than nop in the pipeline during and immediately after the change. 
    _NOP();
     SREG = oldsreg;
     return true;
  }
  SREG = oldsreg;
  return false;
}

This function takes a signed 8-bit integer, which should have a small absolute value (1 notch is 1.5% - so 1-2 notches is all you should need to adjust it by). This way you can keep running at a speed where timekeeping will work correctly and keep F_CPU at 20mhz.
It will set the oscillator cal byte to the value obtained by summing the signed tweak value and the value that is loaded into that register at power on, provided that number is lower than 64, sinc ethe highest number that can be stored in the cal register is 63. It will return true if it did change the osc calibration, and false if you requested a nudge that wouldn't fit in the cal register's 6 bits.

Edit: updated it to be a bit safer. (with the nops (which probably aren't necessary with such a small nudge to the clock) and disabling interrupts so we can't have an interrupt fire as soon as the protected write sequence is done, and hence our nops getting displaced.

[Rollpopptery]

Thanks for this,

I do have a scope.
I made a simple 50uSec pulse with the code below.

I can confirm that all 20MHz derived frequencies are about 4% slow.
The 16MHz derived frequencies (16, 8, 4, 2) are perfect.

My coms errors occur with other 20MHz derived frequencies ( 20MHz, 10MHz)

//Code

// interrupts previously disabled
// 50 uSeconds
void pulse10uSeconds()
{
PORTA.OUTSET = PIN7_bm;

//DELAY_CYCLES(1000); // 20MHz 50uSec pulse
//DELAY_CYCLES(800); // 16MHz 50uSec pulse
//DELAY_CYCLES(500); // 10MHz 50uSec pulse
//DELAY_CYCLES(400); // 8MHz 50uSec pulse
//DELAY_CYCLES(250); // 5MHz 50uSec pulse
//DELAY_CYCLES(200); // 4MHz 50uSec pulse
DELAY_CYCLES(100); // 2MHz 50uSec pulse

PORTA.OUTCLR = PIN7_bm;
}

Thanks !

[SpenceKonde]

Then 2-3 notches added to the calbyte should get it to where it should be. I'd expect it to work if you bumped the cal up like that. More likely 3 than 2.

As for why it works with software serial even though software serial sucks - many software serial implementations exit as soon as they see the stop bit. -so they can use that time preparing So while the UART looks at all 10 bits (including framing) the software serial doesnt pay much attention t o the last