issue with I_GPIO_HOLD_DIS

[0x0fe]

So, this macro, which i try to call from the default wake stub, causes compile error

C:/Users/xxxxl/.platformio/packages/framework-espidf/components/ulp/include/esp32/ulp.h:347:5: error: expected primary-expression before '.' token
     .wr_reg = {\  

C:/Users/xxxx/.platformio/packages/framework-espidf/components/ulp/include/esp32/ulp.h:375:39: note: in expansion of macro 'I_WR_REG'
 #define I_WR_REG_BIT(reg, shift, val) I_WR_REG(reg, shift, shift, val) 

Also referenced here https://github.com/espressif/esp-idf/issues/11875

[boarchuz]

I_GPIO_HOLD_DIS is intended to initialise a ulp_insn_t, which is an instruction for the ULP coprocessor. The wake stub is executed by one of the main CPUs when waking from deep sleep.

These are completely separate things. The ULP has nothing to do with the wake stub.

The error is correct, the macro is basically unexpected garbage to the compiler.

[0x0fe]

oh, i see, but do you know a way to disable the hold from the wake stub? the wakeup stub uses ULP instructions.

[boarchuz]

Follow gpio_hold_dis() until you reach the low level register operations. You can then replicate this using the usual macros (eg. REG_SET_FIELD) or with your own functions that you ensure are in RTC memory (eg. using RTC_IRAM_ATTR).

[0x0fe]

yes, that is what i tried to do, sadly the only reference i could find is in the map and for a compiled library libdriver.a, cant seem to find any source

[0x0fe]

ok i found it manually, for somereason vscode is not capable to find the file but its in rtc_io.c

[boarchuz]

It should be easy to find, you might need to tweak your IDE intellisense settings.

Anyway, it boils down to rtcio_ll_force_hold_disable, for which you'll need the RTC GPIO number for the digital GPIO you're using. See hulp_gtr in this repo for an example of how to do that, or you can simply look it up and hard code it.

Ensure everything is inlined and/or any function you use is in RTC memory else it will not be available in the wake stub.

[0x0fe]

OK i found it in your source indeed, but i realize GPIO16 is not an RTC GPIO, so i have to find another way.