Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error in ULP macro I_WR_REG when trying to use I_GPIO_HOLD_DIS in the wake stub (IDFGH-10643) #11875

Closed
3 tasks done
0x0fe opened this issue Jul 14, 2023 · 3 comments
Closed
3 tasks done
Assignees
Labels
Resolution: Done Issue is done internally Type: Bug bugs in IDF

Comments

@0x0fe
Copy link

0x0fe commented Jul 14, 2023

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.4

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

PowerShell

What is the expected behavior?

expected that I_GPIO_HOLD_DIS can be used from the wake stub.

What is the actual behavior?

In function 'void esp_wake_deep_sleep()':

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)   

Steps to reproduce.

call I_GPIO_HOLD_DIS((gpio_num_t)16); in the default wake stub.

Build or installation Logs.

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)   

More Information.

So, i use ESP32D0WDR2 which has internal 2M PSRAM, just before when entering deep sleep I hold GPIO16 high to avoid a current leak.

  pinMode(16,OUTPUT);
  digitalWrite(16,1);
  gpio_hold_en((gpio_num_t) 16);

However, when waking from sleep the PSRAM fails to initilize (cannot read ID), which makes sense, the GPIO16 is still held high, and for some reason the PSRAM init function do not disable the HOLD.
However, calling

  gpio_hold_dis((gpio_num_t) 16);
  gpio_deep_sleep_hold_dis();
  rtc_gpio_force_hold_dis_all();

At the very beginning of the firmware does not solve the problem, i assume the reason is simply that the PSRAM is initilized either in early boot or even in bootloader, so disabling the HOLD afterwards cannot solve the issue.

Since i use the wake stub for other purposes i figured i should disable the HOLD here, and found this macro, sadly the macro wont compile, i assume there is a trick perhaps related to the scope of some structures used in ulp.h, but i could not find anything.

Just to clarify, the macro i use comes from here : https://github.com/boarchuz/HULP/blob/63266e18e4b3c09ae840dbf72999a36df67ab746/src/hulp_macros.h#L389
Just a wrapper for ulp.h macros.

@0x0fe 0x0fe added the Type: Bug bugs in IDF label Jul 14, 2023
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jul 14, 2023
@github-actions github-actions bot changed the title error in ULP macro I_WR_REG when trying to use I_GPIO_HOLD_DIS in the wake stub error in ULP macro I_WR_REG when trying to use I_GPIO_HOLD_DIS in the wake stub (IDFGH-10643) Jul 14, 2023
@ESP-Marius
Copy link
Collaborator

I think you might be getting some things mixed up here.

ulp.h contains macros intended to be used from the ULP co-processor, while the wake-up stub is code that is ran from the main cpu (but ran at a early stage in the boot up process)

@ESP-Marius
Copy link
Collaborator

Closing this for now, but feel free to reopen if there is still anything unresolved here.

@espressif-bot espressif-bot added Resolution: Done Issue is done internally and removed Status: Opened Issue is new labels Oct 11, 2023
@0x0fe
Copy link
Author

0x0fe commented Oct 12, 2023

Yes sorry, i forgot to close it but it was a mixup of APIs indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

3 participants