Dear All:
I have a very strange issue that has me scratching my head. I am programming a GPIO to provide hardware reset to an i2c GPIO expanver (pcal6408a). The io expander is fully supported in zephyr 4.3.0 mainline (I am using the zephyr 4.3.0 release branch). I have described the pin in the device tree and it compiles cleanly. when I run the init sequence for the io expander the code correctly sets the gpio to S0S1 drive strength, and then pulses the gpio low for 1uS with no returned error codes. Unfortunately when I look at it on the oscilloscope the gpio never goes low.
All of this happens during the initialization that runs before control reaches main(). I looked at the init priorities and everything is happening in the correct order.
Eventually I wrote a loop in main() that simply toggles the gpio P1.04 alternating high and low once per millisecond. When I look at the signal on the oscilloscope it the rise and fall times are good (about 15ns). If I force the drive strength to H0H1 the rise and fall times are about 7ns. This says to me that the hardware is all good, both inside the chip, and on my external wiring. From the rise and fall times, and the rise and fall times published in the datasheet, I can estimate that the capacitance on the line is about 22pF, which seems about right.
Now here is where it gets weird. if I put a break point i the middle of the loop, the rising edge looks great, but the falling edge is very bad. the signal falls the from 3.3V to 1.7V at the normal rate, then the pin goes tristate. It then slowly falls to zero over about 200uS, this is exactly the time you would expect with 22pF and a 10MOhm pull-down, the scope probe is a 10MOhms resistance to ground..
When the processor comes out of reset and attempts to send the reset pulse to the pcal6408a it drives down to 1.7V, then goes tri-state, this is why the pcal6408a never properly resets, and also why I could never catch the reset pulse on the oscilloscope.
At this point I haven't tried a different board, or a different gpio, that is my next thing to try (possibly tomorrow). I did read all of the errata for the nrf5340 and didn't see anything about this issue.
I have two suspicions:
1) somehow the gpiote is programmed to put the pin in tristate if it goes low. I single stepped through the gpiote code that gets run when the pin is configured and the code appears to be turning the gpiote off for this pin.
2) I have a strange setup for the core power. I am using a uBlox NORA module which contains the nrf5340 (date code week 24 of 2025, or week 25 of 2024). I am powering the module from an external 3.3V supply. uBlox documentation doesn't .specify any particular settings I need to put in the UICR. I am using the same settings as the nrf5340dk. Is it possible that I have the UICR programmed incorrectly and this is why the pin goes tri-state on falling edges?
I am looking for some hints of things I could do next to try to find the root cause of the issue.
Thanks in advance for your help.
