Arduino Uno R4 WiFi: GPIO's which are not port 1 in overlay fail to build

[Gerriko]

Describe the bug

I am using the following:
CODE: samples/basic/blinky example.
BOARD: Arduino Uno R4 WiFi

I created the following working overlay to change the default LED (led0)

/*
 * SPDX-License-Identifier: Apache-2.0
 *
 * This overlay changes the default LED for the blinky sample
 * to Arduino D4 (P106).
 */

/ {
	aliases {
		led0 = &d4_led; /* Blinky sample uses led0 alias */
	};

	leds {
		compatible = "gpio-leds";
		d4_led: led_d4 {
			gpios = <&ioport1 6 GPIO_ACTIVE_HIGH>; /* D4 is P106, active high */
			// gpios = <&arduino_header ARDUINO_HEADER_R3_D4 GPIO_ACTIVE_HIGH>;
			label = "User LED D4";
			status = "okay";
		};
	};
};

If I then change the GPIO to Arduino D8. using gpios = <&arduino_header ARDUINO_HEADER_R3_D8 GPIO_ACTIVE_HIGH>; or gpios = <&ioport3 4 GPIO_ACTIVE_HIGH>;

I get a build error.

Upon experimentation, I discovered that only GPIO's using port1 work here.

Regression

• This is a regression.

Steps to reproduce

Save overlay in boards folder.
run: west build -p always -b arduino_uno_r4@wifi

Observe that device tree compiler happy but fails on build.

Relevant log output

/media/files1/Zephyr_Dev/zephyr/include/zephyr/device.h:96:41: error: '__device_dts_ord_33' undeclared here (not in a function); did you mean '__device_dts_ord_36'?
   96 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
      |                                         ^~~~~~~~~
/media/files1/Zephyr_Dev/zephyr/include/zephyr/toolchain/common.h:168:26: note: in definition of macro '_DO_CONCAT'
  168 | #define _DO_CONCAT(x, y) x ## y
      |                          ^
/media/files1/Zephyr_Dev/zephyr/include/zephyr/device.h:96:33: note: in expansion of macro '_CONCAT'
   96 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
      |                                 ^~~~~~~
/media/files1/Zephyr_Dev/zephyr/include/zephyr/device.h:293:37: note: in expansion of macro 'DEVICE_NAME_GET'
  293 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
      |                                     ^~~~~~~~~~~~~~~
/media/files1/Zephyr_Dev/zephyr/include/zephyr/device.h:310:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  310 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
/media/files1/Zephyr_Dev/zephyr/include/zephyr/drivers/gpio.h:334:25: note: in expansion of macro 'DEVICE_DT_GET'
  334 |                 .port = DEVICE_DT_GET(DT_GPIO_CTLR_BY_IDX(node_id, prop, idx)),\
      |                         ^~~~~~~~~~~~~
/media/files1/Zephyr_Dev/zephyr/include/zephyr/drivers/gpio.h:370:9: note: in expansion of macro 'GPIO_DT_SPEC_GET_BY_IDX'
  370 |         GPIO_DT_SPEC_GET_BY_IDX(node_id, prop, 0)
      |         ^~~~~~~~~~~~~~~~~~~~~~~
/media/files1/Zephyr_Dev/apps/blinky/src/main.c:21:40: note: in expansion of macro 'GPIO_DT_SPEC_GET'
   21 | static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);
      |                                        ^~~~~~~~~~~~~~~~
[36/136] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/logging/backends/log_backend_uart.c.obj
ninja: build stopped: subcommand failed.

Impact

Functional Limitation - Some features not working as expected, but system usable..

Environment

• OS: Linux Ubuntu 22
• Toolchain: should all be the latest...West version: v1.2.0, Zephyr 4.1, West version: v1.2.0

Additional Context

No response

[ljd42]

If you look at the resulting build/zephyr/zephyr.dts, you'll see that the D8 pin is using GPIO ioport3. If you check this node, you'll find that the port is disabled: status = "disabled";.

The solution is to enable the port by adding the following lines in your overlay file:

// overlay as before 

&ioport3 {
        status = "okay";
};

[Gerriko]

@ljd42 thanks for highlighting this. That's good to know. I would have expected all ports used in the Arduino R3 pin layout to be enabled by default. Then up to the user to disable by choice in their code.

[ljd42]

@Gerriko : no worries, we're all here to learn 😉

I agree that this choice of disabling ioport3 is rather... surprising... This might be an oversight, or perhaps some clever thoughts that only the original author knows about.

Would you mind to convert this bug to a question if possible and mark it answered? Thanks!

[Gerriko]

Same applies for ioport0 (analog pins A0 - A3) and for ioport4 (D11 and D12).

Surely this issue should remain open, until such time as it's resolved by either someone fixing or scheduling a fix for the issue via pull request, or by clarifying the reason for keeping the anomaly (I don't view this as normal expected GPIO behaviour for an Arduino dev board).

[ljd42]

I understand your expectations. While I agree that the behavior might not be what you are expecting, the following previous statement is no longer valid:

Major – Severely degrades functionality; workaround is difficult or unavailable.

Looking at the DTS structure, the UNO R4 uses a Renesas System-On-Chip (SoC), namely the r7fa4m1ab3cfm. This SoC is used in other boards, where the ioport isn't necessarily configured as on the Uno R4. There's also the concept that hardware gets enabled, only when needed by the user (to save power etc).

The Arduino R4 overlay board (in zephyr/boards/arduino/uno_r4/) could indeed enable the ioport it uses for the arduino headers and documents it accordingly. I think, your proposal could be a neat enhancement.

[Gerriko]

Now that I understand the issue, I've downgraded the issue to: Functional Limitation - Some features not working as expected, but system usable.

I would agree, only the Arduino Uno R4 dts file would need modifying to include the following:

&ioport0 {
        status = "okay";
};

&ioport3 {
        status = "okay";
};

&ioport4 {
        status = "okay";
};

[ljd42]

Hi @Gerriko,

Do you feel like creating your first PR? If not, I can take care of it.