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   

[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.