Problem: FluidNC blocks out pin usage based on restrictive assumptions

[ajquick]

Wiki Search Terms

ESP32 Pinout, Restricted, Mini, U4WDH

Controller Board

Custom

Machine Description

None

Input Circuits

No response

Configuration file

i2so:
  bck_pin: gpio.10
  data_pin: gpio.4
  ws_pin: gpio.9

Startup Messages

Pin 10: Unusable GPIO

User Interface Software

No response

What happened?

My custom board uses an ESP32-U4WDH, not a ESP32-WROOM-32.

These chips should be functionally identical, however between the two chips they have different restricted GPIO.

While the WROOM restricts pins 6-11 for the integrated flash, the U4WDH restricts pins 6-8, 11, 16 & 17 instead.

The restriction of pins is hard coded into FluidNC v3.6.2+

Unless I'm not seeing it, there should be spot to define your chipset in the config file or otherwise override the restrictions.

I'm having to revert to v3.6.1 to go back to before the restriction was imposed.

GCode File

No response

Other Information

No response

[bdring]

We have no experience with that chip. Is v3.6.1 fully functional?

If so, we can consider updating the gpio checker. We have a lot of other priorities right now and you are the first to ask for this. It may take a while.

Are you interested is writing the PR or sponsoring this work?

[ajquick]

I could certainly look at what it would take the make a change. My thought is the software should just check the chipset prior to restricting pins. If it sees WROOM, it should follow through on the check, anything else and it should skip.

Is v3.6.1 fully functional?

I believe so.

Are you interested is writing the PR or sponsoring this work?

My company (me) has sponsored since October 2021, with around $600 contributed. I had to lower my contribution given that COVID pretty much put us out of business... but would be happy to increase contributions should outlooks change.

[MitchBradley]

The restriction was added in response to #630.

Making it configurable could be a can of worms due to the explosion of different ESP32 variants that we are starting to see. It seems like everybody and his brother wants to use something different, to the point where we are going crazy trying to keep up with the churn.

I am looking for something that might make it possible to automatically configure the restrictions based on the chip, but so far I am not finding any UW4DH-specific documentation at all. A search for UW4DH on the Espressif website has no hits - https://www.espressif.com/en/advanced/search?search=uw4dh . The datasheet for that part at Digikey is just the generic ESP32 datasheet that doesn't say anything specific about UW4DH

[ajquick]

Perhaps it is more dependent on the module itself rather than which core is used.

On the ESP32-WROOM this is stated:

Pins GPIO6 to GPIO11 on the ESP32-D0WD-V3/ESP32-D0WDR2-V3 chip are connected to the SPI flash integrated on the module and are not led out.

On the ESP32-MINI:

Pins GPIO6, GPIO7, GPIO8, GPIO11, GPIO16, and GPIO17 on the ESP32-U4WDH chip are connected to the SPI flash integrated on the module and are not led out

What I'm finding is that on several of the Devkits or complete packages, the flash pins are actually fully accessible, which goes against what the datasheet above states.

See page 22 of the ESP32 core datasheet. Basically there is a difference between the hardwiring between the D0WD and U4WDH and the flash on the module.

[MitchBradley]

My difficulty in finding info was partly due to mistyping U4WDH as UW4DH. Do you know of a way to detect whether the chip is a U4WDH?

[ajquick]

Checking. Apparently the information can be obtained by reading the fuses.

$ESP420
Chip ID: 30755
CPU Cores: 2
CPU Frequency: 240Mhz

I'm seeing there might be a function called: ESP.getChipModel() as part of the Espressif SDK core.

In my case this is returned:

ESP32-U4WDH

Or one of the following:

• ESP32-S0WDQ6
• ESP32-D0WDQ6
• ESP32-S0WD
• ESP32-D0WD
• ESP32-D2WD
• ESP32-U4WDH
• ESP32-PICO-V3
• ESP32-PICO-D4
• ESP32-PICO-V3-02
• ESP32-D0WDR2-V3

I believe FluidNC supported models would probably be:

• ESP32-D0WD
• ESP32-U4WDH
• ESP32-PICO

The PICO like the U4WDH apparently restricts pins: 6-8, 11, 16, & 17.

[bdring]

Nice!

Some are single core....won't work.

[ajquick]

Trying to come up with a restricted list based on the datasheets:

Restricted Pins

Pin (GPIO)	Usage	Chip
6	Flash / Ram	All
7	Flash / Ram	All
8	Flash / Ram	All
9	Ram	WROOM / WROVER
10	Ram	WROOM / WROVER
11	Flash / Ram	All
16	Flash / Ram	All except WROOM
17	Flash	All except WROOM

Pins 16 and 17 can be used on the WROOM, but not the WROVER with built in PSRAM. Pins 16 & 17 can't be used on the U4WDH, Pico or WROVER. Pins 9 & 10 are not accessible on the WROOM/WROVER (D0WD), but are accessible on the U4WDH and Pico.

I'm not sure what would be the best way to handle the different chips. I think in the meantime this function should be modified to allow Pins 9 and 10 to be used. If you want to implement a check you would need to handle Pins 9, 10, 16 and 17 on a chip by chip basis.

FluidNC/FluidNC/src/Pins/GPIOPinDetail.cpp

Line 16 in fec80d9

PinCapabilities GPIOPinDetail::GetDefaultCapabilities(pinnum_t index) {

Pin 9 & 10 restricted on all D0WD / WROVER / WROOM (your target audience), but not U4WDH & Pico.
Pin 16 & 17 restricted on U4WDH / PICO & WROVER (with PSRAM), but not WROOM.

For identication's sake, the ESP32 with built-in PSRAM is ESP32-D0WDR2-V3. But that is not a guarantee as a module might have external PSRAM installed.

[RootCNC]

Hi all,

Firstly thank you for the PR, I stumbled across this, before I spent ages head scratching, trying to implement the ESP32-MINI-1U-N4 module and when this came up with your original issue. it was easy to fix - thank you.

Upon testing it would seem there are two additional pins missing form the list:

These seem to work as intended. although I can understand that the intent of this function is to help ensure the user select the correct pins. Would you like me to raise a PR for the additional two pins?