Attiny816 - Serial communication and external oscillator

[delucaide]

Hello gents,
Anyone knows why if I use a 16Mhz external oscillator on the attiny 816 , the bitrate set into the command is not the same as the output?
i tested my code with the internal oscillator option at 20Mhz and all is working good.
when I switch to 16Mhz External, seems that the bitrate slowdown a lot. I found that to have a bitrate close to 57600 which is the speed I need, I have to set the Serial command speed to something like 350.000.
Tried with another attiny chip and the issue is always the same.

Any advise?

[SpenceKonde]

Are you overriding main() or init()? If you override main or init, nothing has run other than the .init sections.

the init sections contain, in order: Clear __zero_reg (r1). Clear SREG. Initialize stack pointer (.init2). At that point, compiled C can now run, and we grab .init3; .init3 will do 2 things. First (unless using a bootloader), it will perform the dirty reset check - reset flags will be checked, if 0x00, we have suffered a dirty reset, have no idea what state the chip is in (execution could have bounced around the flash for an arbitrary time before it finally reaches something that skids to 0x0000 or 0x0002 (which jumps to badisr which jumps to 0) - or it could have gotten there from a bad ISR being called, in which case no reti has run, so RSTCRTL still has LVL0EX set, and will not run any interrupts except the one marked priority (if any)), so no code can be expected to produce any particular result if it depends in any way on the hardware. This is not an acceptable operating regime, yet nobody in arduino land seemsto know about this problem. so in frustration (trying to educate every user that they really shouldbe checking the reset flags and then they must clear them is hopeless), I have the core do what is necessary. This cannot help the fact that there may be both an absence of desired behavior and the presence of undesired behavior immediately prior to a dirty reset (if it's caused by smashing the stack - that case can have almost any behavior during the time between the first return statement after the function return address is corrupted by the smashing of the stack, and the time when an ijmp, icall, or return (which will return to an address that could be anywhere on the flash depending on what you overwrote it with) finally lands after the end of non-empty flash; after that time it is guaranteed to proceed to the reset vector), but after the dirty reset actually occurs (execution reaching 0x0000 without a reset occurring), doing the software reset and then CLEARING THE FLAGS (we stash them in GPIOR0 for application access) so that a future dirty reset can be detected), eliminates the possibility of the presence of undesired/unexpected/undefined behavior and the absence of expected behavior caused by the dirty reset - up until whatever triggers the fault condition and dirty reset happens of course).

Assuming that passed (it will either pass, or fail, software reset, and then pass), .init3 is also where onPreMain() (default: empty function, weakly defined so it can be overridden.

.init4 is concerned with copying data from flash to .bss variables, then .init6 is constructors, and finally .init9 calls main ();

That's all that's done before main(). That's what actually calls init(), which calls init_clock, which is where the code that switches the clock to run at the requested speed is. So if that isn't called it will start up running at 16/6 = 2.67 MHz from internal oscillator. For this reason overriding main is not recommended, and if you do it, you need to call the init functions for the peripherals you want to use, and for the clock.

What main() does is:

• Calls onBeforeInit() (user definable, otherwise empty)
• Calls init() Init in turn calls:
  • init_clock()
  • init_millis()
  • init_TCA0()
  • init_TCD0
  • and so on.
• after init() completes, main calls onAfterInit(). (used definable, default implementation returns 0 and does nothing else).
• Unless onAfterInit() returns a non-zero value, it calls sei() to turn on global interrupts (this allows you to keep global interrupt flag turned off until you turn it on, allowing you to do things in setup that you need to do before any interrupts are enabled).
• It then calls your setup() function, and then calls loop() in an infinite while loop.
  main, and many of the init functions are weakly defined and hence overridable.

If the chip were running at 2.67 MHz (since it default starts at 16/6 or 20/6, and you've probably set the internal clockspeed fuse to 16 MHz, That would require 345600 baud specified to get 57600 baud (since it thinks the clock is 6 times faster than it is)

So IF YOU ARE OVERRIDING main() or init() THIS IS EXPECTED IF YOU DO NOT INITIALIZE THE CLOCK YOURSELF Either don't override those, or be sure to call the necessary functions yourself.

Now, if you're NOT overriding main or init, that implies that the init_clock code that changes to external clock is running The relevant snippet is this:

    _PROTECTED_WRITE(CLKCTRL_MCLKCTRLA, CLKCTRL_CLKSEL_EXTCLK_gc); //tell it to switch to external clock. 
    // while (CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm);  // This either works, or hangs the chip - EXTS is pretty much useless here.
    // w/out CFD, easier to determine what happened if we don't just hang here.
    uint8_t count = 10;
    while (CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm && count--); // check for up to 10 times the time this loop takes to run 
    if (CLKCTRL.MCLKSTATUS & CLKCTRL_EXTS_bm) { //as long as we're now on the external clock source
      _PROTECTED_WRITE(CLKCTRL_MCLKCTRLB, 0x00); // we turn off the prescaler. 
    }

As you can see, if within 10 passes through that loop, we haven't seen enough clock edges on the external clock to switch, we give up, and don't change the prescaler so the user knows immediately that there's a problem with the clock (if we failed to switch to the 16 MHz external oscillator, but did switch the prescaler, you might think you're on the external clock, but still be using the internal clock at the same nominal frequency,and you'd be wondering why he external clock was so much less accurate than they claimed).

That loop should be rendered as lds, andi, breq (past next two isn), dec, brneq (back to the start) - 6 words, and for the case when the clock is failing to switch, those take 2+1+1 (branch not taken) + 1 + 2 (branch taken) = 7 clocks, so you get like 69 clocks in the loop plus 1 before it to set up the loop counter -> 70 clocks, or about 26.25 us. plus the power on reset time of the AVR and a few extra us while the rest of .init runs, plus the overhead of onPreMain() and onBeforeInit() if the user has defined either of those. If the oscillator has not started by then, we figure it aint ever gonna start. So we leave the prescaler on so the user can clearly see that the clock is fucked, and hopefully lead the user to investigate and determine that the clock is not running fix it.

The clock switch should only take 2 clock cycles to occur (unclear which clock - I think the external one) but either way, you easily get there as long as the external clock is running, as that would be 0.75us if it's the internal osc after prescaling or 0.125us if it's the external one. But maybe the external one specifies an unusually long startup time and that's the oproblem.

When it is in this malfunctioning state, Serial.printHexln(CLKCTRL_MCLKSTATUS);
will give you the clock status as a nice hexadecimal number. Bitwise and with 0x91; to extract only the three relevant bits here:

• If 0x01 is set, we told it to switch the oscillators, and it's standing by to do that as soon as it sees a clock signal (but it's not seeing one).
• If 0x10 is set, the internal osc is running, this will be the case if something is requesting that clock
• If 0x80 is set, the external oscillator is running. If this is set, 0x01 should never be set (well, okay, they might be set at the same time for a clock cycle or two, but only a terribly brief window).
• So I expect that you'll find that the value that prints is 0x11 if the external osc is not running.
• If 0x81 or 0x91 is set, this should be a can't happen, and I would need to see code that reproduces this and details of the oscillator being used and how it's connected.
• So 0x90 would mean that it has successfully switched to external clock and something (likely TCD) was using the internal osc, or 0x80 which would indicate a sucessful switch to external clock, and that the internal one was turned off because nothing was asking for it.
• The first nybble will always have at least one out of the low and high bits set - ie, 0x9_, 0x8_, 0x1_, because the only clock sources that run at a frequency suitable for serial correspond to those two bits.

What do those tell us of diagnostic value?

• If 0x80 or 0x90 is seen, than it HAS successfully switched to the external clock. But you say that things are running at 1/6th speed, indicating that the so the prescaler was never turned off. You can confirm by printing Serial.printHexln(CLKCTRL.MCLKCTRLB); - and you would see 0x11: Register layout is 0b000ppppE. where 'pppp' is the index of the prescaler (when the high bit is 1 and all other bits of this field are 0, you get /6 prescale), and E is the enable bit for the prescaler. If it's 0, then the prescaler is off, and therest of the bitfield is being ignored. So if you see 0x11 in MCLKCTRLB, that confirms the presumptive explanation for the 0x80 or 0x90 value yet the wrong F_CPU. If you have a scope, you can also just measure the clock speed by outputting it to PB5 (which you luckily have on 20 pin parts):

// either:
#include <megaTinyCore.h>
// <snip rest of program>
// at start of setup, start outputting the clock so you can measure it on scope (or even with frequency counter):
turnOnClockout();
// OR - you can just do it yourself because that's a three liner! 
uint8_t temp = CLKCTRL_MCLKCTRLA;
temp |= 0x80;
_PROTECTED_WRITE(CLKCTRL_MCLKCTRLA, temp);

In this case, the problem is rather simple: the oscillator is just taking too long to start up and the core has given up by the time it actually starts. The clock source then switches, but the code doesn't know that has happened. The solution has two steps. 1. You must identify the actual startup time seen, and 2. slow down startup before init() is run so that the oscillator is always running by at absolute most, 26us after starting init(). That delay can be achieved by:

• Increasing the SUT (StartUp Time) setting in the fuses and "burn bootloader", which can wait as long as as 64ms.
• Add a delay in onBeforeInit() (this delay must not depend on millis or micros, since those don't exist yet, and the times must be adjusted to account for the fact that you a) don't know if you're running at (20/6=) 3.33/16ths of the speed you think before the clock source switches, or, or 2.67/16ths (1/6th) once it finally does.

delayMicroseconds((known OSC startup time in excess of 26ish us)/6); 

• For longer delays:

#include "util/delay.h"
//<snip>
_delay_ms((time to wait in milliseconds beyond the 26) / 6);

• Using an oscillator that does not suck so much and starts up faster,

On the other hand, if the status remains 0x11 that means the oscillator is not oscillating and that you most recently ran the internal oscillator at 16 MHz, not 20 MHz (otherwise things would be happening 25% faster). Investigate the power connections to the external oscillator, ensure that it has appropriate power being supplied, and so on. Also, if it's one of those ones thats the shape and size of a 4 terminal smd crystal, feel it with your finger. Is it warm/hot? If so, it has failed and must be replaced. Likely you installed it backwards. Vdd and Gnd are on opposite corners of those, and the markings are often difficult to see even using heavy magnification and favorable lighting. With the reverse polarity applied to it, the oscillator burned out within a couple of milliseconds (ie, no matter how fast you catch that mistake, which is extremely easy to make, if you applied power even briefly, you killed it), and is no longer functional. It should be removed as it is now pulling an unreasonable amount of current (I have seen a few hundred mA generally) through the blob of silicon that used to be a key internal part of the oscillator), and replaced if you want an external clock, being extra careful to orient the clock correctly.

Note that this is an external oscillator that it needs (also called an "active oscillator", "TCXO" and similar) is NOT a crystal!

Though some look identical to crystals, a crystal does not help you - the chip doesn't have the internal inverting amplifier needed to make a crystal oscillate (thus far, only AVR DB, DD, and EA-series parts, and classic AVRs released before 2016 support a crystal. The modern tinyAVRs do not, nor do the megaAVR 0-series. The future AVR DD-series will, though the future EB-series (which appears to be aimed squarely at low cost motor control or SMPS applications) will not. The impression I get from that pattern is that the crystal support is relatively expensive in terms of die size, or there are other technical reasons they don't like external crystals.

As I've speculated elsewhere, I don't expect to see any AVRs announced or released that are not AVR<capital letter indicating genus[my term, not official]><capital letter indicating family[this term is used officially]>-named parts, ie, the tinyAVR brand is dead (just like megaAVR was killed after the 0-series. I think Microchip looked at the sales numbers and determined that xMega was dead by the time they took over, they haven't released anything under that branding!). I have no knowledge nor theories about if or when there will be a third genus of modern AVR###XX##-s (AVR Fx would be the natural next letter, and has a nice ring in that it sounds like "effects" But a lot of other letters prefixed with an F would be a little dicey, from a PR perspectice. I can't imagine a native USB part if F was the leading letter - the naming doctrine would seem to demand that to be called an AVR FU, and I think marketing and management would say "No" to that, and there are a lot of other letters that pair with F in ways that the image conscious marketing/management folks would not find nearly as amusing as I do)

[delucaide]

Hi,
First of all, thanks for your reply.
Second, what do you mean with overriding the Main or init?
I just burn the boot loader with different clock speed - internal oscillator 20Mhz = baudrate correct - external oscillator 16Mhz = baudrate incorrect.

Is there any command should i write into the code to use the external oscillator and get the things works well?

[SpenceKonde]

Reread the parts I edited in ( if there are not a lot with bolded headings for important parts), then I didn't click the save button which I can't do atm because I'm sending this from my phone while on the throne. ) Though based on you observation that the speed is 1/6th of the expected speed not 1/6th of 20 mhz (assuming you have run on int 20 more recently than int16) , you're I. The final case where the osc starts so slowly that the core has given up, but then it finally starts, the core de t eats it and switches, but it's no longer in the loop which, when it exits after successfully finding a clock, it clears the prescaler) and hence the preacher remains at /6, but the main clock source has eventually switched (would be nice if we could set an interrupt on the clock source switch and turn off prescaling there, but there isn't

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Mon, Jun 5, 2023, 16:11 delucaide ***@***.***> wrote: Hi, First of all, thanks for your reply. Second, what do you mean with overriding the Main or init? I just burn the boot loader with different clock speed - internal oscillator 20Mhz = baudrate correct - external oscillator 16Mhz = baudrate incorrect. Is there any command should i write into the code to use the external oscillator and get the things works well? — Reply to this email directly, view it on GitHub <#966 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW7KLIBGWPXWMIJQOWLXJY4PVANCNFSM6AAAAAAY2POMZA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[delucaide]

Ok i will try to increase the startup time through the bootloader and see if something change.
The oscillator I’m using is this Murata CSTCE16M0V53-R0
I don’t think it can be reversed in polarity.

[SpenceKonde]

Finished up the above edits and expanded further

[delucaide]

Hello, I tried to move the startup time to 64ms but I still have the issue. Any advise?

[delucaide]

Just seen that the 816 do not support crystal. Is it correct? If so, I have to replace with an active oscillator

[SpenceKonde]

Oh yeah if you are hoping to use a crystal, fuhgeddaboudit. The modern tinyAVRs do not support crystals.. Microchip seem to be on a crusade against external frequency crystals. I have to assume that it occupies significant die area (hence cost) on the chip or something.

Among modern AVRs, only the AVR DB/DD/DU/EA have external crystal support, the tinyAVR 0/1/2 does not, nor does the megaAVR 0-series or the DA-series. (note: only some EA's are released, DU is next after those are out ( this is a big one - it''ll have native USB! finally, which a lot of people want), while the EB-series after that looks to be targeting a lower price point and I'm going to guess it's aimed at a migration path from tiny861 and such - looks extremely motor-controlly from what little information they've shared. A lot will depend on what the new timers on the EB are like, and whether they are going to be common or rare among future part families.

So yeah you either need an external clock (I consider this a last resort - they're expensive, the orientation mark isalmost impossible to see Vdd and Gnd are in opposite corners and reverse polarity destroys them within milliseconds), and they need their own decoupling cap, they don't even get cheap if you buy them from china, they just don't come with part numbers or specs in that case).

Or, you decide that you know, maybe this internal clock is good enough It's not like USART doesn't work, ort it swings 10% over the allowed voltage range like classic AVRs>.> (for more accurate longer term timekeeping you can use a watch crystal on the TOSC pins (though they are INSANELY layout sensitive because they're trying so hard to minimize power consumption) and clock the RTC from that)), Note that just the internal clock is easily good enough for UART serial communication - it's nothing like classic AVRs, where there was both baud rate calculation error and clock skew fighting against UART. Now the internal oscillator is much more tightly calibrated (on the 2-series the factory tuning is even better - If you know you're running them between 3.3 and 5.0 volts, you can assume they they're running at exactly the nominal speed, then use aTCB to time the low frequency internal osc of the PIT then enable prescale /4, and iterate through all the possible tuning values, timing each one against the internal low frequency clock, and you end up with the same tuning values as you do when you run the other turning sketch with a 1kHz reference clock. to figure out the speed of the internal oscillator, and calculate what t should be to get my brain

[delucaide]

All clear mate. I close the discussion. Thanks a lot for your help