best practice - delay between setting pin as input with pull up/pull down and reading the pin

[cp52]

We are seeing a potential issue with a product. on start up a pin is read and the read value determines if we go in to a test mode. Pretty standard. 

Our failure is during normal operation when there is nothing connected to this pin and the firmware is reading a low instead of a high. (On test a test fixture will take the pin to ground)

1. During normal operation there will be nothing connected to the pin so it is init ally floating floating.
2. When the firmware starts we set the pin to input and immediately read the value of the pin on the next line

nrf_gpio_cfg_input(TEST_PIN, NRF_GPIO_PIN_PULLUP);
if (!nrf_gpio_pin_read(TEST_PIN)) 
{
	runTestMode();
}

So the question is should I put a delay in between setting the pin as an input with a pull up and reading the pin?

Is it good practice to put a delay in?

(i could of course add an external pull up)

Essentially I will need to look:

1. The time between the pull up being connected internally to the pin, to when the pin state is read.
2. the capacitance of the line and the time it takes for the line to go "high" once the pull up has been connected. 

27/7/2018: extra info/questions

Extra marks for considering issues on power up. I.e. assume this code is one of the first things to run.

Nrf51. Pull up values in section 8.23 of the datasheet.

Additional Information:

Please read this post here: https://devzone.nordicsemi.com/f/nordic-q-a/25873/internal-pull-up-resistance-on-gpio-of-nrf51822 

It has a interesting reply on the pull up value with respect the supply voltage on power up. This might depend on how you have the brownout settings configured and when the code is triggered as the voltage rises on power up. equally we may never see this if the code never gets run on supply voltages <1.8V   

[AmbystomaLabs]

Offhand, I believe everything on the gpio is delayed by one pclk. So, the delay depends on how you have pclk configured.

Yes, it is normal practice to delay a few clocks after setting a register as registers rarely set and latch state on the same clock edge.  Normally I would just throw in a few NOP's after writing the config register depending on the spec for the device.

The pullup is spec'd as 13kohm so there is no need to worry about the capacitance unless you added one on the pin.

[RK]

You don't say whether you're using nRF51 or nRF52. On nRF51 the answer is no, you don't need a delay, the APB and CPU run at 16MHz and everything is synchronous. On nRF52 however the APB still runs at 16MHz but the CPU runs at 64MHz and has write caching so it can take up to 4 cycles for data to actually be written to the register. Reads on the APB bus block so they're fine. So on nRF52 you do need to ensure the status write to the register has occured before you read the value. 

The recommended way of doing that is to read back the configuration you just set, ie read back the gpio config register which nrf_gpio_cfg_input() just set. That forces the bus to stall until the write has completed at which point the register input value can be used. 

Checks the implementation of that macro/function/whatever it is to see if Nordic already added that readback into the call. For safety's sake they should have done (on the  nRF52) but I don't know if they did for performance reasons. 

// update

I just did look at the macros in SDK15.0 and they don't readback the register, so if you're on  nRF52, you should do so. Either you do it using the actual register (which rather negates the point of having the hardware abstraction layer) or find a function which implicitly reads it like `nrf_gpio_pin_sense_get()`. Just look at the source, pick a method you like. 

TLDR;

nRF51, no need, nRF52, need to read back the configuration (not the value) register after you write it to ensure  it's been written. 

[cp52]

I am using the nrf51 however we use the nrf52 as well so this is great a a forum reply. 

[cp52]

You have pointed out that on the nrf51 we are synchronous and we can guarantee that the pull up gets connected to the pin before we read. However people should still make sure they consider what is on that line and consider the relevant time that the line will take to be "pulled up". 

[AmbystomaLabs]

I noticed RK didn't respond to you.

Again, the peripherals are all driven by pclk. So if you write the config register on one pclk on the next pclk the new value will be set (ie, latched). So you should not attempt a read until the third pclk.

If the register writes are being cached as RK stated, then you will have to wait longer since the register write will not be synchronous with the opcode.

On nRF51 if you just throw in half a dozen NOP's between the config and read, you should have compensated for any latency. If you don't like embedding assembly code then just add a for loop to hold up the processor for a few clocks.