Can someone confirm something about the IO for me. To get a input will pull up, setting the mode to GPIO_MODE_USER_STD_INPUT_PULLUP isn't enough , the oeb and out signal need to be driven to 0 & 1 respectively ? I thought that mode would enable the pullup no matter what and so in the chip I have oeb set to 1 and out set to 0 to disable the output buffer but I couldn't observe the pullup and re-reading the doc, I think tha might be the issue why I'm not seeing the pullup on the IO.

Just for background (I think you've figured this out already): The I/O pads have a very weird setup for pullup and pulldown. Rather than just coupling in a resistor to power or ground like you might expect, they just couple a series resistor from the output buffer to the pad (specifically, they have separate resistors on the negative and positive sides of the output buffer, so that the output buffer can drive one direction strongly while it drives the other direction weakly). The pullup or pulldown function is then a combination of (1) connecting the series resistor from output buffer to pad, and (2) turning on the output buffer and setting it to 1 (pullup) or 0 (pulldown). Now some of the pad configuration is manipulated inside the

gpio_control_block

module. As you noted above, the DM setting that enables pull-up or pull-down has to be combined with OEB set to zero and the output value set to 1 (pullup) or 0 (pulldown).

gpio_control_block.v

line 239 specifically overrides the output value appropriately for pullup or pulldown function. The caveats are: (1) There is no equivalent override for OEB, mainly because it's just a configuration bit; and (2) There is no automatic override of the output value for user, as opposed to management, pullup or pulldown mode. Number (2) seems to be an oversight, while (1) is intentional. Conclusions: (1) The bit definitions for GPIO_MODE_[USER/MGMT]_STD_INPUT_[PULLUP/PULLDOWN] all need to clear bit one or else the function won't work properly. That means the definitions should be fixed as follows:

#define GPIO_MODE_MGMT_STD_INPUT_PULLDOWN  0x0801
#define GPIO_MODE_MGMT_STD_INPUT_PULLUP    0x0c01
#define GPIO_MODE_USER_STD_INPUT_PULLDOWN  0x0800
#define GPIO_MODE_USER_STD_INPUT_PULLUP    0x0c00

And (2), For the two user modes, the output must be set appropriately to 0 for pulldown function and 1 for pullup function, and this oversight should be corrected for the next version of caravel/caravan.

Thanks for confirming. My logic doesn't drive the output / output enable pins properly so nothing I can do about that, but needing an external pull up isn't a big deal ( compared to the rest 😅 )

Yes, that should work!

Oh yeah, I run it at ~1.326V and there is only a range of ~ 10-20 mV where it works. Exact value depend on the die.

That matches my experience exactly, within limited statistical variation. I got two boards sent to me by Jeff. One worked, the other didn't. The one that worked would only work at a specific voltage in an approximately 10mV range.

Is there some power sequencing requirements btw ? On my test bed I have this weird issue where the chip dos nothing (despite repeated resets) when I have the chip plugged into the test bed when I power the test bed. I have to unplug the chip and replug it for it to start working ... not really sure what's up with that. Or maybe it doesn't like slow power ramp-up ( voltage being driven from a buffered RC filtered PDM means very slow rampup on power on ... ).

The one thing I can think of is that the power-on-reset circuit is generating a 15ms delay after detecting a good 3.3V supply before lifting reset. However, that's done assuming some future version with on-board LDOs. With an off-chip 1.8V supply, you could end up with unknown behavior if you brought up the 3.3V supply first, and the 1.8V supply came up more than 15ms later. Which could entirely depend on the specific LDO chips used.