[En-Nut-Discussion] undefined reference to NutArchClockGet

[Ulrich Prinz]

Hi Darell,

AFAIK NUT_CPU_FREQ is declared via nutconf. It must be set to the CPU
clock for any CPU. So with AVR it must be set to the crystals clock, or
if CLKDIV8 fuse is set, it must be crystal/8.
For ARM and Cortex it should be set to the core clock what is the
frequency of the CPU after the PLL.

> function `NutGetCpuClock':
> timer.c:(.text+0x164): undefined reference to `NutArchClockGet'
> collect2: ld returned 1 exit status
> make: *** [simple.elf] Error 1
> 
> That function is declared in five files:
>      nut/arch/arm/dev/ostimer_s3c4510b.c
>      nut/arch/arm/dev/ostimer_at91.c
>      nut/arch/arm/dev/ostimer_lpc2xxx.c
>      nut/arch/avr/dev/ostimer.c
>      nut/arch/unix/dev/ostimer.c
>      nut/arch/avr32/dev/ostimer.c
> 
> I think I'd expect the declaration in nut/arch/arm/dev/ostimer_at91.c to be
> used, but that declaration is only included if NUT_CPU_FREQ is not defined.
> I haven't determined whether NUT_CPU_FREQ is supposed to be defined or
> not...
> 
I found a NUT_CPU_FREQ problem when porting to STM32 Cortex CPUs. The
initial idea was to detect the clocks automatically. But it doesn't
match as ARM/Cortex allows varieties of clock constellations. So in
Cortex I implemented it the other way round. Here you must define this
clock and therefore the PLL setup is done fully automatically.
This enables you to develop with full speed and later try to find lowest
working speed with lowest power consumption with only modifying one
nutconf setup entry or compiling define.

For AT91 I am actually at it to port all changes and improvements from
Cortex back to AT91.

Ok, so far the explanation.
To solve your problem #define NUT_CPU_FREQ with the speed of your CPU
core (after the PLL). In ostimer_at91.c this is set to 73728000. Check
if that part is enabled.

The clocks are a bit tricky as most chips support many different ways of
setup causing lots of #ifdefs in flexible code.

Ulrich