'RTC_CLKSEL_INT32K_gc' was not declared in this scope

[mrWheel]

How do I solve this?

//=============================================================
void RTC_init(void)
{
  /* Initialize RTC: */
  while (RTC.STATUS > 0)
  {
    ;                                   /* Wait for all register to be synchronized */
  }
//             vvvvvvvvvvvvvvvvvvvvv 'RTC_CLKSEL_INT32K_gc' was not declared in this scope 
  RTC.CLKSEL = RTC_CLKSEL_INT32K_gc;    /* 32.768kHz Internal Ultra-Low-Power Oscillator (OSCULP32K) */

  RTC.PITINTCTRL = RTC_PI_bm;           /* PIT Interrupt: enabled */

  RTC.PITCTRLA = RTC_PERIOD_CYC16384_gc /* RTC Clock Cycles 16384, resulting in 32.768kHz/16384 = 2Hz */
  | RTC_PITEN_bm;                       /* Enable PIT counter: enabled */

} //  RTC_init()

[mrWheel]

I found this one:

  RTC.CLKSEL = RTC_CLKSEL_OSC32K_gc;

Would like to know how long one sleep_cpu() takes ..

[SpenceKonde]

Where;s that code from? Is that code of mine? Ugh, I really wish they would use consistent names for stuff

[SpenceKonde]

I don't think it is? Oh it could have been your code? Because you were on a 3216, which is one of the two 1-series parts where that code would work correctly.

[mrWheel]

Where;s that code from? Is that code of mine? Ugh, I really wish they would use consistent names for stuff

I'm afraid so:

Here

[SpenceKonde]

Oh! I wasn't the one who wrote it, it's tinyAVR code that was brought over without any testing - and I haven't been paying much attention to the stopgap doc page because I'm going to release a sleep and RTC management library, which can manage tracking of millis while in standby sleep using RTC then upon waking up, switch back to a "real" timer.

I don't think that code will work correctly on any tinyAVR except 3216 and 3217, which is the one two they've released silicon with fixes to the RTC errata that impacted 0/1-series and megaAVR 0-series You had to have both RTC and PIT on, or things would behave weirdly (microchip just described it as one not working without the other being enabled. bit's much worse than that. It's actually like really perverse, like, after you turn on one, if you leave the RTC itself off, the status always shows it busy syncing count and the while (RTC.STATUS); hangs.. and even with that, the prescaler would reset with every write to RTC.CTRLA or something. That peripheral is super flaky on the early modern parts. It works correctly on 2-series and Dx though, only a of the original bugs are still with us today, The 2-series errata list is like 5 items! It's amazing. DA and DB are.... still pretty ugly that way, though not nearly as bad as the tinies. I suspect the fact that all product releases have been super-delayed is related. (like 2-series was). Though I don't know whether they're just trying to release a more polished producct because they have the luxury of a 1 year order backlog, they brought someone to crack the whip on not releasing products with so many bugs (Particularly this time last year, microchip released a part which they had never tested running an interrupt on. Like, it wouldn't run blink (because the interrupt vector table was 2-byte instead of 4-byte on a 32k chip, and the compiler of course was generating code assuming the correct size. they recalled the chips from distributors, never posted anything, and one of their poor engineers was telling people on avrfreaks to contact microchip suppoert for replacements. That'sthe closest they came to admission. I still have a bunch of those defective chips lol.

Not sure if it takes any significant time enter sleep, check the sleepctrl chapter of datasheet, I didn't see go to sleep, only wake up times. sleep_cpu() itself is just do {__asm__ __volatile__ ("sleep" "\n\t":: );} while (0)

MOST of avrlibc is just stuff like that - if it involves assembly at all - of the functions it provides are just a line or two of C writing to registers.

The do { __asm__ __volatile__ (inline assembly);} while (0) is an ideom to try to make sure that there's no way avr-gcc can fuck it up It is unclear whether it works at all and whether it's redundant with making the assembly volatile but avrlibc uses it everywhere.

sleep instruction itself is listed in avr manual as 1 clock, but it's kind a of a weird instruction, and the description refers you to the applicable datasheet

[mrWheel]

Hm.. so if I read it correctly the AVR-DB series are not really production ready? I had my hopes high on these chips.

RTC_CLKSEL_OSC32K_gc will set the cpu to sleep for about 14 seconds. RTC_CLKSEL_OSC32K_gc sets the cpu to sleep for ~500ms.

the fact that it “seems to work” is (no) garantee the MPU will crash in any moment in time? … will it help to enable the WDT just before gooing to sleep(will it reset if, for one reason or another, the sleep_cpu() will not wake-up?

(If only the ATmega328 had three UARTS…)

I don't have to ask you in what timeframe you will release the sleep and RTC management library(?!). I desperately need a power saving mode!

[SpenceKonde]

I wouldn't say that at all. The DA-series is kinda rough, but the DB is better anyway so who would use DA? The 0/1-series tinyAVRs have never gotten fixes, but they're widely used in production devices. A

You of course need to read the errata. But you should always read the silicon errata, if it's on a different document.... not reading the silicon errata is always asking for trouble.

I would NEVER use a classic AVR in 2021. The product line is dead. Development ended over half a dozen years ago. The peripherals had been stale for the half dozen years before that. Atmel had expected XMega to be the future. XMega was too complicated. It was not the huge success they hoped (having skimmed some pieces of the datasheets, investigating history of some peripherals on modern AVRs I coulda told them nobody was gonna buy them. Gratuitous complexity, what happens when you don't account for the usability cost of additional features, only the silicon cost...)

The modern AVRs were made by looting the bodies of the two architectures and in most cases improving on the combination, while cutting away wonky useless stuff that xmega had.I think they eventually realized that one of the AVRs biggest assets is the developer appeal of it's design simplicity. They're not lacking in capabilities, but they don't have a lot of bizzare peripherals with strange interactions or that work only on specific pins during a the first new moon of the fiscal year...

Anyway, the DB is not that bad in terms of errata on the A5 silicon (came out last fall iirc - pushed out quickly, I think in part because of the two opamp issues that were raining on their new peripheral. )

The list is down to mostly the universal modern AVR bugs, that all the post-2016 ones have, and that most everyone is aware of and/or which are worked around by the core like the TCB 16-bit register not being treated as 2 independent registers in 8-bit pwm mode (you have to write it like a 16-bit reg, which reminds me DxCore needs that fix), the ccls not being unless you first disable the CCL as a whole is (I thought that was intended), the TCA restart commabnd resetting direction (but that's what the datasheet says it does! Do they read their own datasheets?!), some obscure thing with TCD async events that almost nobody cares about, and the TWI and USART pin override glitches which are widely documented and worked around (TWI can only override direction not output value, so if it's ever set high, it will stop working because it won't be able to drive the bus low, only high, that's why you never ever call pinmode or digitalWrite on pins after starting up the TWI, the library carefully works around this bug in begin()). The USART in ODME on the other hand only works correctly when set as input, otherwise it will drive the pin high anyway).... Oh, and there's a stupid bug if you're trying to wake from sleep on USAERT start of frame detection - you've gotta turn it off in the before reading the receive3d character otherwise if it's receiving the subsequent character, it'll screw upthe boundaries between characters. Impacts all modern avrs, was only added to errata last year, I think they had a hard time figuring out what was going on).

Uh, You can't run the PLL off an external crystal (burt you can run it from system clock if that's using crystal), Does anyone care? No.

It only has one that I still consider really really bad: TCD pwm comwa out of all 4 pins if you ask for it on the first pin, or not at all except when using the default pion mapping, So basically you can only remap TCD's by using the CCL which is... not ideal.... I am very frustrated with this, because I have all the code written to make analogWrite() mux-value-aware, except the errata is still not fixed. It will definitely not be broken on the DD though - they're adding new mappings and are aware of the bug, and very aware of pin pressure there. The. A5 revision fixed a lot of bugs on the DB.

There is a weird power consumption issue if it is above 2.1v, and then falls to a value between around 1.9 and 2.1v, wastes some power as long as it's around there in terms of voltage - sounds like the internal voltage regulator is getting confused; thats right about the voltage where it would need to be changing modes I wager. It doesn't happen if the voltage doesn't go over the ~2.1. But why am I writing this? Just look at the errata: https://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DB28-32-48-64-SilConErrataClarif-DS80000915B.pdf

The DA's are..... much worse, particularly the 128k flash version... https://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DA28-32-48-64-SilConErrataClarif-DS80000882B.pdf

And the tinyAVR 0/1-series, has a huge number of bugs, and noty all parts have all bugs, and only the 3216 and 3217 got meaningful fixes, for the most part.

[mrWheel]

@SpenceKonde Wow! It is incredible how much time you spent on those Microchip products. They must pay you a lot to make these available to “the public”! (I know they don’t, but they should!!).

Some background of me: I’m 67 years old and my pedigree is COBOL programming. My knowledge of C(++) and the microprocessors is that of an “end-user” (I write C++ like you would write COBOL). Most of what you (and MX682X) write about registers, clocks and stuff is far over my heat.

At last I have read the eratta and believe only 2.12 is important for this issue(?) but than it goes all dark for me. No idea how to solve it.

I know it is (again) much to ask for but I would really appreciate a peace of example code to get the MCU to sleep for a wile like the example you gave me for the T3216 as I’m a bit in a hurry to get this project up-and-running switching from the T3216 to the AVR-DB chips (eliminating I2C and three multiplexers).

[SpenceKonde]

I'm going to be working on this core over this weekend as it is clearly broken in several ways, We need more people who are as willing to report issues as you are. It's suddenly clear that DxCore isn't as "clean" as megaTinyCore is, which has faced more people pointing out bugs as well as development attention recently as the push to add the 2-series parts occurred. Whereas this core has not been the primary target of development in recent times.

[SpenceKonde]

This now gets transparently corrected, as we do when Microchip changes names of options for no good reason. In the next version of the includes, they straight up rename a bitfield from FREQSEL to FRQSEL. including on the parts they have been selling for 18 months