Read GPIO immediately after configured

RE: Read GPIO immediately after configured

XavierYin — Mon, 26 Aug 2019 16:11:29 GMT

I'm using SES V4.20 macOS

As far as I understand:

1. SES projects should be able to work cross-platform
2. flashing .hex file (from full erase) should put the board into the same state
3. should be able to see debug output through RTT after flashing the provided .hex

But, of course, thank you anyway. You make me feel less alone. Thank you.

RE: Read GPIO immediately after configured

hmolesworth — Mon, 26 Aug 2019 16:04:31 GMT

Time for comments from a Nordic engineer, hopefully. I am unable to look at MAC files (I am using SES V4.20 on Windows 10), and don't have any spare time just now. hex files don't help as we can't see debug output, I don't think.

RE: Read GPIO immediately after configured

XavierYin — Mon, 26 Aug 2019 15:28:47 GMT

There's only PCA10040, nothing else.

It's so weird that the same project behaves differently...

Could you try this binary, and could you please share your binary?

devzone.nordicsemi.com/.../blinky_5F00_pca10040.hex

RE: Read GPIO immediately after configured

hmolesworth — Mon, 26 Aug 2019 15:09:04 GMT

I get this, which is expected:

<info> app: [0000000B] 1 1 1 1 1

I ran some sanity tests, all pass:

STATIC_ASSERT( 0 == (GPIO_PIN_CNF_DIR_Pos),   "Error - GPIO_PIN_CNF_DIR_Pos");
STATIC_ASSERT( 1 == (GPIO_PIN_CNF_INPUT_Pos), "Error - GPIO_PIN_CNF_INPUT_Pos");
STATIC_ASSERT( 2 == (GPIO_PIN_CNF_PULL_Pos),  "Error - GPIO_PIN_CNF_PULL_Pos");
STATIC_ASSERT( 8 == (GPIO_PIN_CNF_DRIVE_Pos), "Error - GPIO_PIN_CNF_DRIVE_Pos");
STATIC_ASSERT(16 == (GPIO_PIN_CNF_SENSE_Pos), "Error - GPIO_PIN_CNF_SENSE_Pos");

STATIC_ASSERT(0x000003 ==
                   ((NRF_GPIO_PIN_DIR_OUTPUT       << GPIO_PIN_CNF_DIR_Pos)   |
                    (NRF_GPIO_PIN_INPUT_DISCONNECT << GPIO_PIN_CNF_INPUT_Pos) |
                    (NRF_GPIO_PIN_NOPULL           << GPIO_PIN_CNF_PULL_Pos)  |
                    (NRF_GPIO_PIN_S0S1             << GPIO_PIN_CNF_DRIVE_Pos) |
                    (NRF_GPIO_PIN_NOSENSE          << GPIO_PIN_CNF_SENSE_Pos)), "PIN_CFG Error");
STATIC_ASSERT(0x00000 ==
                   ((NRF_GPIO_PIN_DIR_INPUT        << GPIO_PIN_CNF_DIR_Pos)   |
                    (NRF_GPIO_PIN_INPUT_CONNECT    << GPIO_PIN_CNF_INPUT_Pos) |
                    (NRF_GPIO_PIN_NOPULL           << GPIO_PIN_CNF_PULL_Pos)  |
                    (NRF_GPIO_PIN_S0S1             << GPIO_PIN_CNF_DRIVE_Pos) |
                    (NRF_GPIO_PIN_NOSENSE          << GPIO_PIN_CNF_SENSE_Pos)), "PIN_CFG Error");
STATIC_ASSERT(0x00002 ==
                   ((NRF_GPIO_PIN_DIR_INPUT        << GPIO_PIN_CNF_DIR_Pos)   |
                    (NRF_GPIO_PIN_INPUT_DISCONNECT << GPIO_PIN_CNF_INPUT_Pos) |
                    (NRF_GPIO_PIN_NOPULL           << GPIO_PIN_CNF_PULL_Pos)  |
                    (NRF_GPIO_PIN_S0S1             << GPIO_PIN_CNF_DRIVE_Pos) |
                    (NRF_GPIO_PIN_NOSENSE          << GPIO_PIN_CNF_SENSE_Pos)), "PIN_CFG Error");

I take it there is nothing plugged into pin 11, such as an expansion board? If that were the case, you would see a slower rise/fall time on the pin which would affect your results

RE: Read GPIO immediately after configured

XavierYin — Mon, 26 Aug 2019 13:48:08 GMT

devzone.nordicsemi.com/.../5460.blinky.zip

upload a sample SES project that repeats the problem

hmolesworth would you mind to try this?

RE: Read GPIO immediately after configured

XavierYin — Mon, 26 Aug 2019 02:15:02 GMT

Your experiments are interesting.

But with nrf_gpio_cfg_input I think it alway connects input buffer with pull, isn't it?

RE: Read GPIO immediately after configured

XavierYin — Mon, 26 Aug 2019 02:13:27 GMT

[quote userid="65515" url="~/f/nordic-q-a/51385/read-gpio-immediately-after-configured/205988"]First the latter point of a 200k pull-down resistor not holding the pin low; the internal pull-up NRF_GPIO_PIN_PULLUP is typically 13k so a 200k external resistor to Gnd will not pull down the input pin voltage far enough to fall below the '0' threshold, so reporting '1' is correct.[/quote]

I did recognize 13k internal pull resistor so I expected the exactly the same results to be observed both on PCA10040 & my custom board. For discussion on Devzone I guess sticking to official EVBs will do better.

RE: Read GPIO immediately after configured

hmolesworth — Sun, 25 Aug 2019 21:12:37 GMT

Out of curiosity I repeated your test and disagree with your findings. Your test does raise some useful questions, however.

First the latter point of a 200k pull-down resistor not holding the pin low; the internal pull-up NRF_GPIO_PIN_PULLUP is typically 13k so a 200k external resistor to Gnd will not pull down the input pin voltage far enough to fall below the '0' threshold, so reporting '1' is correct.

Using the code posted (and no setup code preceding this code) I see continuous '1' values where expected, regardless of configs. eg:

    nrf_gpio_cfg_default(GPIO_PIN_TO_TEST);
    nrf_gpio_cfg_default(GPIO_PIN_TO_TEST);
    nrf_gpio_cfg_default(GPIO_PIN_TO_TEST);
    nrf_gpio_cfg_default(GPIO_PIN_TO_TEST);
    nrf_gpio_cfg_input(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_PULLUP);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);

Result:
<info> app: [11] 1 1 1 1 1

Now the interesting part is where is the pull-up or pull-down applied; the schematic in the v1.4 datasheet implies after the input disconnect. Here I pre-charge the input pin by first pulsing it as an output, then return to an input and read in all modes:

    // Precharge pin to '1':
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    nrf_gpio_pin_set(GPIO_PIN_TO_TEST);
    // Now read pin in all modes:
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_PULLDOWN, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);

    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);
    nrf_gpio_cfg(GPIO_PIN_TO_TEST, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_PULLDOWN, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);
    read_result[0] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[1] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[2] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[3] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    read_result[4] = nrf_gpio_pin_read(GPIO_PIN_TO_TEST);
    NRF_LOG_INFO("[%d] %d %d %d %d %d", GPIO_PIN_TO_TEST, read_result[0], read_result[1], read_result[2], read_result[3], read_result[4]);

The results are as expected but interesting:

<info> app: [11] 1 1 1 1 1
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 1 1 1 1 1
<info> app: [11] 0 0 0 0 0

'1' when reading back the output, but when reading back as inputs the only time '1' is read is when the input is connected and the pull-up is selected. With pull-up selected but input disconnected we get a '0', which means the pull-up/pull-down in the schematic is incorrectly shown as downwind (closer to the cpu) than the input connect switch.

Pre-charging the pin with '0' gives the same results.

<info> app: [11] 1 1 1 1 1
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 0 0 0 0 0
<info> app: [11] 1 1 1 1 1
<info> app: [11] 0 0 0 0 0

The reason '0' is read when input is disconnected regardless of pull-up or pull-down is given by the Feed-through issue handling:

"When a pin is configured as digital input, care has been taken in the nRF52832 design to minimize increased current consumption when the input voltage is between VIL and VIH. However, it is a good practice to ensure that the external circuitry does not drive that pin to levels between VIL and VIH for a long period of time."

Feed-through is unwanted increase in power by current Ist travelling between Vdd and Gnd not through the input pin but through the input FETs when the input voltage lies within the vanishingly small window where both FETs are slightly turned on: