How to check float as hex value?
In general, when you're looking at the bit representation of data in memory, you only have two options:


Use a pointer to the variable, and "lie" as to what it is pointing to:


  Note @erebos' and @Lundin's comments below: while you'll often see something like the following, it is NOT strictly conformant C. That "lie" could bite you...


volatile float f;
volatile uint32_t *p = (volatile uint32_t *)&amp;f; // Take the address of f and cast it.
...
if (*p!=0xFFFFFFFFu) {
    printf("%f", f);
} // if

Use a union structure to change its interpretation depending on what field you acccess:

typedef union FloatAs32 {
    volatile float f;
    volatile uint32_t i; // "Overlays" other fields in union
} FloatAs32;

FloatAs32 f;
...
if (f.i!=0xFFFFFFFFu) { // Access 'i' field
    printf("%f", f.f);  // Access 'f' field
} // if



I say "in general", because you may also have the opportunity to rely on the encoding of the float to get what you want. I'll need to check my references, but it may be that you can test for NaN, which is a special representation of floats to indicate (literally) "Not a Number" (such as sqrt(-1);)

Your test if (f==0xFFFFFFFF) tries to compare the interpreted value of the float against that number. You want to compare against the uninterpreted value.

Edit

I checked my sources, and I was right. If the "Exponent" field is all 1s, and the "Mantissa" field is not all 0s (which matches your case in general, but not specifically all Fs), then the float is interpreted as a NaN. Note that the "Sign" bit is used to distinguish between a "Quiet" NaN (can be propagated through calculations) and a "Signalling" NaN (can cause exceptions). Luckily, a "Sign" bit of 1 (as in your case) is a QNaN.

That means that you can simply use the isnan(f) function and it will return true for your special case - and other cases too. Does your device produce a NaN at any time? Perhaps to indicate an error condition? If so, you shouldn't use this suggestion. If not... that's your call.

Edit #2

@dwelch made a good point in the comments about using volatile. The compiler could keep its values in registers rather than memory, so neither example above would have worked. Adding volatile tells the compiler to always read and write the values to memory rather than caching them. I've modified my examples to take this into account.