Sanity check

[FernandoGarcia]

Related area

GPIO usage and chip features compatibily

Hardware specification

All boards

Is your feature request related to a problem?

We have discussed here about a problem of incompatibility between GPIO usage and ESP32 PSRAM feature.

The example switch the RainMaker library uses GPIO 16 as outupt at same time this GPIO is used by PSRAM feature that is enabled by default for ESP32 chip.

So it has caused an error of memory allocation when using the core 2.0.7.

Moreover there's others problems like GPIO 1 and 3 being used as INPUT or OUTPUT together with serial monitor and so on.

Also, we have found a number issues like E (355) gpio: gpio_set_level(226): GPIO output gpio_num error . This error message doesn't explain the root of the problem and doesn't help so much.

Describe the solution you'd like

To solve this problem I have proposed a implementation called sanity check similar to feature used in Marlin Firmware where the features compatibilities are checked to each feature enabled on sketch.

In this case the compatibility between GPIO usage on sketch and CHIP features are checked.
In case of incompatibility an compiling error will shown with clear description of the problem, so the user can fix it without ask in forums or here the meaning of such error.

Describe alternatives you've considered

No response

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[me-no-dev]

This is not necessary. The problem comes from RainMaker and will be fixed. We should not have such issues in the future.

[FernandoGarcia]

This is not a particular issue with RainMaker.

Looking for this documentation for example we can see that the misusage of GPIO 6 to 11 can result in unexpected behaviour.

[igrr]

FWIW, in IDF v5.1 we are adding a feature to reserve the GPIOs; this will take care of Flash/PSRAM conflicts, among other things. So this might be addressed in arduino-esp32 v3.0 without extra work required.

[Jason2866]

ESP32 variants (pico) do have PSRAM connected to other GPIOs. So general fixed sanity checks makes no sense at all. Provided examples should avoid GPIOs which are dangerous.
A solution would be to detect the exact MCU version and type (esptool.py) and provide the info of dangerous GPIOs of the connected ESP32 variant.

[FernandoGarcia]

As I told before...

To make it work to all boards you can use a bunch of #ifdef like Marlin firmware does. :)

Well, I'm talking about something like this pseudocode:

int gpio_get_level(gpio_num_t gpio_num);
{
  if(gpio_num == 16)
  {
    return true;
  }
  return false;
}

#if defined(ESP_32) && defined(USE_PSRAM)
  if(gpio_get_level(16) == true)
    {
      #error "GPIO 16 can't be used when PSRAM is enabled"
    }
#endif

[Jason2866]

you forgot GPIO18 and GPIO23 which can be used for PSRAM too, and for ESP32-S2 ESP32-S3? And this are just recommendations. You can connect PSRAM to nearly every GPIO.
Just a define in sdkconfig in IDF. A lot of ITEAD devices do NOT use GPIO 16/17 for PSRAM.

[FernandoGarcia]

I don't have pretension to cover all situations with this example.

[Jason2866]

It will be a fight against windmills. If the user don't know exactly what board (MCU Variant) used this will be a useless attempt. If knowing this is not needed at all, since avoiding because knowing restricted GPIOs
I know this problem well. We solve this in Project Tasmota by detecting the chip and revision and do Auto detection of PSRAM. With this infos we disable the not useable GPIOs in the Tasmota config menu.

[FernandoGarcia]

Ok, you gave your opinion now wait for others.