can GPIO read a HIGH due to internal pull up

[swetha_krishnam]

I am using MCF5272 and trying to use a previously unused GPIO pin to give me indication of a new capability on the next board spin. On the existing board the port A GPIO pin was unused, set as output and not connected (floating?) . The idea was that in the next board spin, we would pull the pin low using an external pull-down resistor. MCF5272 GPIO documentation indicates that there are internal pull up resistors , so expectation was that when this port pin is made an input instead of an output and when the pin is read, it will read a HIGH (even though the pin doesn't have any external pull ups or pull downs)  where as the next board spin would have this pin deliberately pulled LOW and so would provide the distinction we need. But it is not working this way.

In my boot application if I first write a '1' to the data register PADAT and then set the data direction register PADDR to make the port pin an input, then I consistently read back a '1' . If I don't follow this sequence and simply configure the PADDR and read, it reads a '0'.  

   Write32Register(MCF5272_PACNT,0x00000000);   

   Write16Register(MCF5272_PADAT,0x3310);
   Write16Register(MCF5272_PADDR,0x7910);

I follow the exact same initialization sequence in the application code but I cannot read back a '1', it keeps reading a '0'.

Question  -

1) Is the presumption of reading a HIGH on this pin due to internal pull-up wrong? 

2) Why does the same initialization sequence result in different results  in boot and application?

3) Should I be doing anything different to try and get a reliable read out of this not-connected GPIO pin ?

I cannot really hook a probe or look at the voltage on this pin as leads aren't exposed on the board.

[TomE]

The chip is acting as documented.

17.1 Overview

To avoid indeterminate read values and reduce power consumption, internal pull-up resistors are active immediately upon reset, and remain active until the corresponding port direction registers are programmed.

Also:

17.3 Data Direction Registers

When these registers are first written, any internal pullups on the corresponding I/O pins are disabled.

This is also mentioned in the Chip Errata (MCF5272DE.pdf), Item 7.

Your code "reading back a 1" may be reading back a floating pin rather than reading back the pullup. It may be staying "high" on stray capacitance for long enough for the read to complete. You can't rely on that. You can see if that is what is actually happening by putting a 100k pulldown on the pin and see if it now reads as zero.

I think you can make this a reliable test by changing the BOOT code to read the pin BEFORE it writes to the Port Direction Register. Then save that result and pass it to the Application code some other way (in memory, on stack, as a parameter and so on). I don't think you can (or should) try and make the Boot and Application separately try to make this decision. The Boot should be the code that "knows about the hardware" and should insulate the Application from that if you can.

Tom

[swetha_krishnam]

Thank you Tom,

Your suggestion makes sense. I am not going to rely on the floating pin and have changed my approach for identifying the new board.