Output driver not working for P1.13 on nRF5340 DK

I am trying to set up two GPIOs to control an external chip. Development and testing is currently using the nRF5340 DK. NCS version is 2.5.0.

In my nrf5340dk_nrf5340_cpuapp.overfile, I have the following. There are other GPIOs, but ignore those for now. Also, ignore the fact that reset should be an open-drain. I am just sanity testing right now. The pins are not connected and only being monitored with a logic analyzer.

/ {
    gpiocustom {
        compatible = "gpio-keys";
        gpiocus1: gpiocus_1 {
            gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
            label = "nRST";
        };
        gpiocus2: gpiocus_2 {
            gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
            label = "MFIO";
        };
    aliases {
        max32664reset = &gpiocus1;
        max32664mfio = &gpiocus2;
    };
};

In the code we have:

static const struct gpio_dt_spec gpio_sh_reset = GPIO_DT_SPEC_GET(DT_ALIAS(max32664reset), gpios);
static const struct gpio_dt_spec gpio_sh_mfio = GPIO_DT_SPEC_GET(DT_ALIAS(max32664mfio), gpios);

and then to test it we have the following declarations

    gpio_pin_configure_dt(&gpio_sh_reset, GPIO_OUTPUT_HIGH);
    gpio_pin_configure_dt(&gpio_sh_mfio, GPIO_OUTPUT_HIGH);

and test code

    for(int i = 0; i < 3; i++)
    {
        k_msleep(500);
        gpio_pin_set_dt(&gpio_sh_mfio, 0);
        k_msleep(500);
        gpio_pin_set_dt(&gpio_sh_reset, 0);
        k_msleep(500);
        gpio_pin_set_dt(&gpio_sh_mfio, 1);
        k_msleep(500);
        gpio_pin_set_dt(&gpio_sh_reset, 1);
    }

asd

The MFIO pin (P1.14) moves. The reset pin (P1.13) does not. I have done a lot of tracing to determine exactly where the problem is occurring. It happens at:

reg->PIN_CNF[pin_number] = cnf;

When the pin configuration gets changed from input-with-pullup to output. This is in nrf_gpio_reconfigure() and is occurring in the secure domain at 0x50842a34. The nRF Debug peripheral registers view does not seem to give access to GPIO P1 in the secure domain, so I am using gdb commands in the debug console to set and verify the P1_S registers and observing the result via Saleae logic analyzer. I must do this while still in the nrf driver functions or I lose privilage to access 0x50000000 register range from the debug console.

Here are my observations:

Set P1.13 high via pullup, *((uint32_t*)0x50842a34)=0xC, pin goes high.

Set P1.13 low via pulldown, *((uint32_t*)0x50842a34)=0x4, pin goes low.

Set P1.13 to output, *((uint32_t*)0x50842a34)=0x3, pin goes low and stays low regardless of state of P1->OUT bit 13. I have set and cleared the bit by using *((uint32_t*)0x50842808)=0x2000 and *(uint32_t*)0x5084280c)=0x2000. The pin state does not change. 0x50842a34 verifies that it is in output mode, owned by APP CPU, with drive set to S0S1 (i.e. register = 0x03). When I change P1.14 using *((uint32_t*)0x50842808)=0x4000 and *((uint32_t*)0x5084280c)=0x4000, that pin does change.

One thing I noticed, if I have the pin in input-with-pullup state and then set it to output, it doesn't go straight to 0. It decays to 0 as though it's draining through something (possibly the Saleae?). That's why I suggest that it seems the output driver is not even connected when PIN_CFG[13].DIR is set to output.

I have searched around in the nRF5340 product specification and on the PCA10095 schematic and cannot figure out anything that would be interfering with P1.13.

Parents
  • Ah, never mind. I have found the source of the problem:

        uart3_default: uart3_default {
            group1 {
                psels = <NRF_PSEL(UART_TX, 1, 12)>,
                    <NRF_PSEL(UART_RTS, 1, 10)>;
            };
            group2 {
                psels = <NRF_PSEL(UART_RX, 1, 11)>,
                    <NRF_PSEL(UART_CTS, 1, 13)>;
                bias-pull-up;
            };
        };

    It seems that this must be affecting OUT_OVERRIDE, DIR_OVERRIDE or both. That is my problem.

  • On further investigation, I see that the overlay view in VS Code does have a squiggle underline for the conflict and does provide a pop-up saying there is a conflict when hovering over the underlined value.

    I am going to change this ticket to a feature request. Would it be possible to have this conflict cause a build failure, or is it considered valid to do this?

  • Aaron F said:

    On further investigation, I see that the overlay view in VS Code does have a squiggle underline for the conflict and does provide a pop-up saying there is a conflict when hovering over the underlined value.

    I am going to change this ticket to a feature request. Would it be possible to have this conflict cause a build failure, or is it considered valid to do this?

    Are you referring to yellow squiggly lines as shown in this image? 

    Regarding the feature request we would prefer you raise the request in another ticket dedicated with that topic.

    Kind regards,
    Andreas

Reply
  • Aaron F said:

    On further investigation, I see that the overlay view in VS Code does have a squiggle underline for the conflict and does provide a pop-up saying there is a conflict when hovering over the underlined value.

    I am going to change this ticket to a feature request. Would it be possible to have this conflict cause a build failure, or is it considered valid to do this?

    Are you referring to yellow squiggly lines as shown in this image? 

    Regarding the feature request we would prefer you raise the request in another ticket dedicated with that topic.

    Kind regards,
    Andreas

Children
  • I am talking about this, with the squiggle under the pin number 13.

  • Ah, I see. Yes, this is as you've concluded in your discussion, i.e that the GPIO has been assigned to other nodes that is not "free to use" since it is predefined to be used to something else on the board. Another example is of course the GPIO's that are connected to NFC, buttons and LEDS. A build error is triggered if the configuration has faulty syntax, but it does not trigger a build error in this case since it is "valid" to overlay a GPIO pin select

    The best way to see the predefined assignments (in combination with examining the PS) is to see the board files. Board files are found under \zephyr\boards\arm, or in the extension 

    Kind regards,
    Andreas

Related