#define OSCR0   0x40A00010


    #define OSCR0   ((int volatile) 0x40A00010)

makes no difference; sampling OSCR0 returns the same value no matter how many times it's sampled.

Compiling with all optimizations off fixes the secondary issue. 

But the primary issue remains: sampling OSCR0 in a tight loops seems to hang each sampling for almost 2 microseconds.

I've got an application that needs at least 1 microsecond resolution on the timer.  It's also got lots that it has to get done between sampling OSCR0, so it can't afford to hang for ~700 instruction cycles. 

Does anybody at gumstix have a clue about what's going on here?

----- Original Message ----
From: David Cary <>
To: General mailing list for gumstix users. <>
Sent: Wednesday, December 26, 2007 11:57:29 PM
Subject: Re: [Gumstix-users] nanosleep

Dear Tom Shepard,

> Date: Sat, 22 Dec 2007 13:30:28 -0800 (PST)
> From: Tom Shepard <>
> Here's the core of the test (OSCR0 is defined as 0x40A00010):
>    getmem(OSCR0);
>    for (i = 0; i < N; i++) {
>        times[i] = getmem(OSCR0);
>    }
>    for (i = 0; i < N; i++) {
>        printf("%u\n", times[i]);
>    }
> Here's something else that's funny: if you remove the first getmem(OSCR0),
> the sample values never change, even over 3000 samples.

Dear Tom Shepard,

I'm mystified by the other things you mention, but "values never
change" is a classic sign of missing "volatile" declarations.

I suspect that OSCR0 should be defined as something like
#define OSCR0 ( (int volatile *)0x40A00010 )
If somehow it is being defined as
#define OSCR0 ( (int *)0x40A00010 )
then the compiler may (or may not) "optimize" away repeated reads,
re-using the first read cached in a register, giving the "values never
change" problem you see.

I've heard that some compilers have had a bug, causing them to
improperly ignore the "volatile" qualifier in some specific programs
under some specific optimization levels -- do you still get the
"values never change" problem if you re-compile with all optimizations
turned off?