Avoiding race in a sub-millisecond TOD timer
Carefully examine all possible interactions between interrupts
There are many possible ways interrupts can happen, you should take some time and carefully try to map them out. I think you missed a few corner cases in case where usecs() is called from a higher priority context than timer_isr(). First, given your description, the function usecs() can be called either from a low or a high priority context:
Low priority call to usecs()
It's either not called from an interrupt context, or from an interrupt with a lower priority than the timer overflow interrupt. In this context, usecs() might be interrupted by timer_isr() at any point during its execution. So look at all the possible places where the timer_isr() could fire:
// 1
uint32_t counter1 = timer-&gt;COUNTER;
// 2
uint32_t ticks1 = ticks;
// 3
uint32_t counter2 = timer-&gt;COUNTER;
// 4
uint32_t ticks2 = ticks;
// 5

Before I am going to look at all 5 possibilities, I'm also going to make some assumptions:

Any higher interrupts together will never take more than 100 milliseconds. This should be reasonable, and avoids us having to worry about the timer overflowing twice while usecs() runs.
The COUNTER effectively gets reset to PRELOAD by the hardware during the interrupt to timer_isr(). You must verify this by reading the documentation of the MCU.

So now for the five possibilities of where the timer reset happens, and after the four statements have run the results will be:

ticks1 == ticks2 and counter1 &gt; counter2 (trivial case)
ticks1 == ticks2 and counter1 &lt; counter2 (only counter2 is valid)
ticks1 != ticks2 and counter1 &lt; counter2 (either ticks1+counter1 or ticks2+counter2 are valid)
ticks1 != ticks2 and counter1 &gt; counter2 (only ticks1 is valid)
ticks1 == ticks2 and counter1 &gt; counter2 (trivial case)

It looks like your code handles all these cases correctly.
High priority calls to usecs()
Here we can never be that timer_isr() interrupts usecs(), but it could be that usecs() interrupted timer_isr(). Let's look at those cases separately.
usecs() did not interrupt timer_isr()
The question is now, what happens when the timer resets? Again, check the documentation of your MCU, but I am assuming that COUNTER will be reset to PRELOAD, just that timer_isr() doesn't fire because we are already in a higher level interrupt. So now ticks1 == ticks2 will always be true. We still have the five positions where the reset can happen:

counter1 &gt; counter2 (ticks1 and ticks2 are behind)
counter1 &lt; counter2 (ticks2 is behind)
counter1 &lt; counter2 (ticks2 is behind)
counter1 &gt; counter2 (everything is valid)
counter1 &gt; counter2 (everything is valid)

Oops, you cannot distinguish case 1 from cases 4 and 5 just by looking at the counter values. The TIMER_STATUS_IF flag also doesn't help in distinguishing what happened, at least not if you check it after reading the counters. So you have to read the counter again:
if (timer-&gt;STATUS &amp; TIMER_STATUS_IF) {
    // The counters wrapped somewhere prior to exactly this if-statement.
    // We assume it won't wrap again from here, because all interrupts will
    // be handled in less than 100 ms.
    counter2 = timer-&gt;COUNTER;
    ticks2 += 1;
} ...

usecs() did interrupt timer_isr()
In a way this looks simpler, because we know the counter reset just before usecs() was called, so we don't have to worry about the counters being able to reset during usecs(). However, now we have to worry about where exactly in timer_isr() we had the higher level interrupt. Again there are several possibilities:
// 1
ticks++;
// 2
timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF;
// 3

Oops, there is no way to distinguish case 1 from case 2 from usecs()! Reordering statements won't help here, there will always be a point right before and one right after the increment. The only way I see is to ensure both ticks++ and timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF are executed atomically. Perhaps this can be done by having timer_isr() disable higher level interrupts:
cli(); // disable all interrupts
ticks++;
timer-&gt;STATUS &amp;= ~TIMER_STATUS_IF;
sei(); // reenable interrupts

This should make usecs() work correctly.