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. 

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

[RK]

I didn't reply  because I had nothing more to add. I agree with the last post from the OP that you need to consider the rise time on the line, that's the only thing you need to consider however. 

There is no need for an extra 'wait' condition with the nRF51. The pullup is activated on the edge of the clock cycle on which you write, if you do a read on the next cycle it's sampled just around the next edge, there is no extra clock cycle latch in there you need to compensate for. You have most of one full 16MHz cycle for the signal to rise.Unless you have a slow rise/lots of capacitance you have enough setup time. 

On the nRF52 you only need to ensure that the write to the status register has been committed and the pullup enabled before you read the value. As register writes are cached that just requires reading back the status register after you write it because the read will stall until the status write commits. Reading the value is another APB cycle later and so you're back where you were with the nRF51, nothing extra required. 

So with nRF51, write status then read value on the next cycle is fine and with nRF52 write status, read status then read value is enough. 

All that is contingent on having reasonable rise times on the signal itself, you need to calculate it, but at 16MHz it would not usually be an issue. 

[AmbystomaLabs]

All good info.

Can you provide a link to the register spec that states it sets and latches state on the same clock?

I couldn't find anything in the Nordic docs and was loathe to start combing through generic ARM documentation. The information could prove useful for later questions.