"I'm wrong again... :-( "

It was a natural assumption given the reported problem. Unfortunately I don't think the OP posted the code that actually caused the problem he reported.

"But I agree with Michael: it'd be far better not to use floating-point for the crystal frequency - the integer number of Hz would be fine."

Well indeed, so do I. If intermediate values occur during the calculation that are not exactly representable in IEEE754 then there may be a possibility of getting the wrong result.

We know that implicit or explicit conversion from float to integer at runtime is done by simply truncating the float value. I don't know whether the compile time arithmetic follows the same rule - if it does one would stand a reasonable chance of getting the result out by one. Does anyone know what rules the compiler has to follow?