#error "CLOCK_SOURCE not defined.
Switched to using version 2.6.11 and am now getting this error. Tried adding #define CLOCK_SOURCE=0 to my code, but still get error. Source of error seems to be in Arduino.h, timers.h or wiring.c in code like this:
#ifndef CLOCK_SOURCE #error "CLOCK_SOURCE not defined. Must be 0 for internal, 1 for crystal, or 2 for external clock" #endif
Is this a known issue?
For background, I'm using megaTinyCore with batch compile/link scripts and not with the Arduino IDE. This approach is still in development, so I could be doing something wrong. My main source of confusion is that I can't find any reference to CLOCK_SOURCE (except in header files), so I'm unclear how to handle this in my scripts. The version of megaTinyCore I used before (3 or 4 years old) does not seem to require any define for a CLOCK_SOURCE value. So. i'm unsure what changes I need to make to use the newer 2.6.11 version. Ideally, it would seem that, if undefined, CLOCK_SOURCE would default to using the internal oscillator.
Wayne
p.s. I regressed to megatinycore2.6.10 and that seems to work as expected. So, perhaps 2.6.11 needs a bit more work.
How the way you need to get those directives into the compiler depends on at what level your scripts are yanking it around.
Like, are you using arduino-builder tools?
C:\arduino-1.8.19-windows\arduino-builder -compile -logger=machine -hardware C:\arduino-1.8.19-windows\hardware -hardware C:\Users\Spence\AppData\Local\Arduino15\packages -hardware C:\Users\Spence\Documents\Arduino\hardware -tools C:\arduino-1.8.19-windows\tools-builder -tools C:\arduino-1.8.19-windows\hardware\tools\avr -tools C:\Users\Spence\AppData\Local\Arduino15\packages -built-in-libraries C:\arduino-1.8.19-windows\libraries -libraries C:\Users\Spence\Documents\Arduino\libraries -fqbn=DxCore:megaavr:avreb:chip=avr16eb32,clock=20internal,bodvoltage=1v75,bodmode=disabled,eesave=enableenable,resetpin=reset,millis=tcb1,printf=default,attach=allenabled,startuptime=8,wiremode=mors,appspm=no,WDTtimeout=disabled,WDTwindow=disabled,flmap=lockdefault -ide-version=10819 -build-path C:\Users\Spence\AppData\Local\Temp\arduino_build_91614 -warnings=all -prefs=build.warn_data_percentage=75 -verbose C:\Users\Spence\AppData\Local\Temp\untitled101685402.tmp\sketch_nov14a\sketch_nov14a.ino
is an example ofwhat the IDE does for compiling a sketch (well, not exactly, obviously that's from DxC)
You notice that the
fqbn=DxCore:megaavr:avreb:chip=avr16eb32,clock=20internal,bodvoltage=1v75,bodmode=disabled,eesave=enableenable,resetpin=reset,millis=tcb1,printf=default,attach=allenabled,startuptime=8,wiremode=mors,appspm=no,WDTtimeout=disabled,WDTwindow=disabled,flmap=lockdefault
holds all the menu options (for the part I happened to have up - you can get an example for any part by compiling a blank sketch for it with verbose compile enabled and it's like the second or third line from the top (one can also painstakingly figure out what each option is abbreviated as from boards.txt, but it's much easier to let the IDE do it for you)
arduino builder then uses boards.txt and platform.txt to determine the full list of -D directives that get passed to the compiler:
Using board 'avreb' from platform in folder: C:\Users\Spence\Documents\Arduino\hardware\DxCore\megaavr
Using core 'dxcore' from platform in folder: C:\Users\Spence\Documents\Arduino\hardware\DxCore\megaavr
Detecting libraries used...
"C:\\arduino-1.8.19-windows\\hardware\\tools\\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++17 -ffunction-sections -fdata-sections -fshort-enums -flto -mrelax -fpermissive -Wno-sized-deallocation -fno-exceptions -fno-threadsafe-statics -Wno-error=narrowing -w -x c++ -E -CC -mmcu=avr16eb32
-DF_CPU=20000000L
-DCLOCK_SOURCE=0
-DTWI_MORS_SINGLE
-DMILLIS_USE_TIMERB1
-DCORE_ATTACH_ALL
-DLOCK_FLMAP
-DFLMAPSECTION1
-DARDUINO=10819
-DARDUINO_avreb
-DARDUINO_ARCH_MEGAAVR
-DDXCORE=\"1.6.0\""
-DDXCORE_MAJOR=1UL
-DDXCORE_MINOR=6UL
-DDXCORE_PATCH=0UL
If your scripts are entering at this level and aren't specifying an FQBN or using Arduino Builder, but are instead directly providing the -D list; you need to make sure you always specify CLOCK_SOURCE as appropriate:
0x00 = Internal
0x02 = External Clock
and on the other core, if parts support it:
0x01 = Crystal
0x08 = PLL from Internal (EB, LA only thus far, likely EC as well - this doesn't increase max speed, rather, the high speed clock it generates is used to supposrt special features on new peripherals)
0x09 = PLL from external crystal (likely EC only when EC comes out)
0x0A = PLL from external clock (EB/LA/etc only)
Tools menu options are used to define things when the C rules prohibit it from being made to work using more normal methods. Things that have to get defined as tools menu options need the define to be propagated back to the core libraries, because we need to do conditional compilation on it with the preprocessor. So It doesn't matter that you've defined CLOCK_SOURCE (though #define should never have an equals sign, while -D directives do) in the sketch, because it isn't while compiling your sketch proper (the cpp file that Arduino creates as an intermediate), it's erroring while compiling some other .c file in the core (I have that trap in several places to try to make it impossible to compile anything without passing the required parameters, a policy enacted after I wasted days trying to track down a problem that was caused by a non-standard build environment, him not specifying clock source, and bizarre behavior appearing (which didn't reproduce for me, as they hadn't mentioned the non-standard compilation environment, so why would I have tried to use that?! Especially since don't use those tools normally.)
It'll take me a bit of time to unpack all this information but, thanks for taking the time to write such a detailed response. I really appreciate it!
Wayne
On Fri, Nov 14, 2025 at 3:07 AM Spence Konde (aka Dr. Azzy) < @.***> wrote:
SpenceKonde left a comment (SpenceKonde/megaTinyCore#1250) https://github.com/SpenceKonde/megaTinyCore/issues/1250#issuecomment-3532226001
How the way you need to get those directives into the compiler depends on at what level your scripts are yanking it around.
Like, are you using arduino-builder tools?
C:\arduino-1.8.19-windows\arduino-builder -compile -logger=machine -hardware C:\arduino-1.8.19-windows\hardware -hardware C:\Users\Spence\AppData\Local\Arduino15\packages -hardware C:\Users\Spence\Documents\Arduino\hardware -tools C:\arduino-1.8.19-windows\tools-builder -tools C:\arduino-1.8.19-windows\hardware\tools\avr -tools C:\Users\Spence\AppData\Local\Arduino15\packages -built-in-libraries C:\arduino-1.8.19-windows\libraries -libraries C:\Users\Spence\Documents\Arduino\libraries -fqbn=DxCore:megaavr:avreb:chip=avr16eb32,clock=20internal,bodvoltage=1v75,bodmode=disabled,eesave=enableenable,resetpin=reset,millis=tcb1,printf=default,attach=allenabled,startuptime=8,wiremode=mors,appspm=no,WDTtimeout=disabled,WDTwindow=disabled,flmap=lockdefault -ide-version=10819 -build-path C:\Users\Spence\AppData\Local\Temp\arduino_build_91614 -warnings=all -prefs=build.warn_data_percentage=75 -verbose C:\Users\Spence\AppData\Local\Temp\untitled101685402.tmp\sketch_nov14a\sketch_nov14a.ino
is an example ofwhat the IDE does for compiling a sketch (well, not exactly, obviously that's from DxC)
You notice that the
fqbn=DxCore:megaavr:avreb:chip=avr16eb32,clock=20internal,bodvoltage=1v75,bodmode=disabled,eesave=enableenable,resetpin=reset,millis=tcb1,printf=default,attach=allenabled,startuptime=8,wiremode=mors,appspm=no,WDTtimeout=disabled,WDTwindow=disabled,flmap=lockdefault
holds all the menu options (for the part I happened to have up - you can get an example for any part by compiling a blank sketch for it with verbose compile enabled and it's like the second or third line from the top (one can also painstakingly figure out what each option is abbreviated as from boards.txt, but it's much easier to let the IDE do it for you)
arduino builder then uses boards.txt and platform.txt to determine the full list of -D directives that get passed to the compiler:
Using board 'avreb' from platform in folder: C:\Users\Spence\Documents\Arduino\hardware\DxCore\megaavr Using core 'dxcore' from platform in folder: C:\Users\Spence\Documents\Arduino\hardware\DxCore\megaavr Detecting libraries used... "C:\arduino-1.8.19-windows\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++17 -ffunction-sections -fdata-sections -fshort-enums -flto -mrelax -fpermissive -Wno-sized-deallocation -fno-exceptions -fno-threadsafe-statics -Wno-error=narrowing -w -x c++ -E -CC -mmcu=avr16eb32 -DF_CPU=20000000L -DCLOCK_SOURCE=0 -DTWI_MORS_SINGLE -DMILLIS_USE_TIMERB1 -DCORE_ATTACH_ALL -DLOCK_FLMAP -DFLMAPSECTION1 -DARDUINO=10819 -DARDUINO_avreb -DARDUINO_ARCH_MEGAAVR -DDXCORE="1.6.0"" -DDXCORE_MAJOR=1UL -DDXCORE_MINOR=6UL -DDXCORE_PATCH=0UL
If your scripts are entering at this level and aren't specifying an FQBN or using Arduino Builder, but are instead directly providing the -D list; you need to make sure you always specify CLOCK_SOURCE as appropriate:
0x00 = Internal 0x02 = External Clock and on the other core, if parts support it: 0x01 = Crystal 0x08 = PLL from Internal (EB, LA only thus far, likely EC as well - this doesn't increase max speed, rather, the high speed clock it generates is used to supposrt special features on new peripherals) 0x09 = PLL from external crystal (likely EC only when EC comes out) 0x0A = PLL from external clock (EB/LA/etc only)
Tools menu options are used to define things when the C rules prohibit it from being made to work using more normal methods. Things that have to get defined as tools menu options need the define to be propagated back to the core libraries, because we need to do conditional compilation on it with the preprocessor. So It doesn't matter that you've defined CLOCK_SOURCE (though #define should never have an equals sign, while -D directives do) in the sketch, because it isn't while compiling your sketch proper (the cpp file that Arduino creates as an intermediate), it's erroring while compiling some other .c file in the core (I have that trap in several places to try to make it impossible to compile anything without passing the required parameters, a policy enacted after I wasted days trying to track down a problem that was caused by a non-standard build environment, him not specifying clock source, and bizarre behavior appearing (which didn't reproduce for me, as they hadn't mentioned the non-standard compilation environment, so why would I have tried to use that?! Especially since don't use those tools normally.)
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/1250#issuecomment-3532226001, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIDM4W5YBOJYEDB7TT2TAL34WZXVAVCNFSM6AAAAACKIO2DX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZSGIZDMMBQGE . You are receiving this because you authored the thread.Message ID: @.***>