nrf_gpio_pin_read and optimized code might return wrong value

RE: nrf_gpio_pin_read and optimized code might return wrong value

Bruno Randolf — Tue, 30 Jul 2019 09:28:55 GMT

Just ran into this as well with SDK15.3.0. The issue is neither fixed nor documented in the SDK docs... I would argue it should be fixed in the SDK as this is a pretty basic functionality...

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Wed, 30 May 2018 07:36:43 GMT

Happy to help. My apologies about the post.

RE: nrf_gpio_pin_read and optimized code might return wrong value

martin-ve — Wed, 30 May 2018 07:33:05 GMT

It was mine, I was already wondering why I couldn't find my post or your reply xD.

Anyway, thanks for your answer.

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Wed, 30 May 2018 07:12:47 GMT

I accidentally deleted a post here, and I'm unable to undo it or find the name of the poster. I copied the text before I deleted the post though, and here it is:

POST:

We've experienced the same issue. When a read of the IN register is executed right after the instruction
where the PIN_CFG is written, it returns a wrong value (always 0?). When we add 4 consecutive (dummy)
reads of PIN_CFG, as suggested in the workaround for errata 173, it works.

Shouldn't this issue be mentioned in the errata? And also include it in the SDK?

The following code works for me:

__STATIC_INLINE void nrf_gpio_cfg(
uint32_t pin_number,
nrf_gpio_pin_dir_t 
dir,
nrf_gpio_pin_input_t input,
nrf_gpio_pin_pull_t pull,
nrf_gpio_pin_drive_t 
drive,
nrf_gpio_pin_sense_t sense)
{
NRF_GPIO->PIN_CNF[pin_number] = ((uint32_t)dir << 
GPIO_PIN_CNF_DIR_Pos)
| ((uint32_t)input << GPIO_PIN_CNF_INPUT_Pos)

| ((uint32_t)pull << GPIO_PIN_CNF_PULL_Pos)
| 
((uint32_t)drive << GPIO_PIN_CNF_DRIVE_Pos)
| ((uint32_t)sense << 
GPIO_PIN_CNF_SENSE_Pos);

#if defined(NRF52) || defined(NRF52_SERIES)
/*
* A read of the IN register 
immediately after a write to PIN_CFG[pin] might result in a wrong value.
* We suspect a 
synchronization issue with the CPU and GPIO clock, similar to PAN173.
*
* Any read on the system 
bus will require the write buffer to be emptied first.
* Synchronize with the 16MHz GPIO clock. This 
takes at least 3 cycles to take effect.
*/
(void)NRF_GPIO->PIN_CNF[pin_number];
(void)NRF_GPIO- 
>PIN_CNF[pin_number];
(void)NRF_GPIO->PIN_CNF[pin_number];
(void)NRF_GPIO->PIN_CNF[pin_number];
#endif
}

ANSWER:
You are right. There is a propagation delay on the GPIO->IN register of a couple of cycles. The number of cycles appears to depend on the IC variant and use case, but should never be more than 3. The system architects are currently discussing how to improve the description of errata 173.

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Tue, 19 Sep 2017 10:17:47 GMT

You can just leave it open and we will see what happens.

RE: nrf_gpio_pin_read and optimized code might return wrong value

Tamisoft — Tue, 19 Sep 2017 09:10:48 GMT

Will do! Do you want me to close this ticket, or the SDK team will write their response here?

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Tue, 19 Sep 2017 08:39:10 GMT

I tend to agree regarding incorporation in the SDK. However, the argument against it is that fixing this corner case will affect other implementations and that we should rather improve our documentation to help people decide on an implementation themselves. I have notified the SDK team so that they can look into it.

Please keep me posted.

RE: nrf_gpio_pin_read and optimized code might return wrong value

Tamisoft — Tue, 19 Sep 2017 06:48:23 GMT

Thanks for the possible solutions, but would it be better to incorporate these into the SDK where it can cause undeterministic output? I mean everywhere else this just manifests as a slight latency (or jitter in it), but in the scenario where IO changes direction it leads to a wrong value read under certain conditions (like optimized enough code generated by the compiler that the two instructions follow closely). The idea about NRF_GPIO->OUT is the same as nops, one is not enough :). ISB and DMB could be a solution, I will test it later, but still I think it should be in the SDK, so from the user's point of view it is consistent.

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Tue, 19 Sep 2017 06:19:09 GMT

Can you try to add a "dummy instruction" after nrf_gpio_cfg_input()? Something like this:

nrf_gpio_cfg_input(7,NRF_GPIO_PIN_NOPULL);
(void)NRF_GPIO->OUT;
if (nrf_gpio_pin_read(7)==0)
    [....]

You can also use __ISB() eller __DMB(). The theory being that it might be because the nRF52's peripherals run at 16 MHz while the CPU runs at 64 MHz. It might be worth a shot to use one of these instructions to ensure that the CPU buffers are empty. Here is a somewhat sparse documentation of the issue.

RE: nrf_gpio_pin_read and optimized code might return wrong value

Tamisoft — Thu, 14 Sep 2017 13:12:16 GMT

Yes, it is a 1.8V system. I mentioned above that we have suspected the capacitance so we have tried to tie the gpio directly to 1.8V as well. If you want we could try to replicate this on one of the nrf52 dks as well, but that might take some time.

RE: nrf_gpio_pin_read and optimized code might return wrong value

MartinBL — Thu, 14 Sep 2017 11:08:18 GMT

I suppose your 10k resistor and the nRF52's pad capacitance can slow down the voltage rise time on the input just enough so that it doesn't reach a logic '1' fast enough for nrf_gpio_pin_read().

But before I report this to the SDK team, is your nRF52's supply voltage also 1.8V? To register as a logic 1 the input voltage must be higher than 0.7*Vdd (electrical GPIO specs).