NANO arduino_nano_header: connector pin issues.

[KurtE]

Describe the bug
As mentioned in the now closed thread:
#45 (comment)

Some of the IO pins on the NANO 33 are not working properly. As @mjs513 mentioned, some of the pins are not working,
Note: I removed from below the ones that actually work:

0 n
1 n
7 n
8 n
10 Just stays high
18 n
19 n
21 n 

I believe most of the issues have to do with the file: arduino_nano_header.dtsi (in zephyr)
Currently:

		gpio-map = <0 0 &gpio1 3 0>,   /* D0 / UART-TX */
			   <1 0 &gpio1 10 0>,  /* D1 / UART-RX */
			   <2 0 &gpio1 11 0>,  /* D2 */
			   <3 0 &gpio1 12 0>,  /* D3 */
			   <4 0 &gpio1 15 0>,  /* D4 */
			   <5 0 &gpio1 13 0>,  /* D5 */
			   <6 0 &gpio1 14 0>,  /* D6 */
			   <7 0 &gpio0 9 0>,   /* D7 */
			   <8 0 &gpio0 10 0>,  /* D8 */
			   <9 0 &gpio0 27 0>,  /* D9 */
			   <10 0 &gpio1 2 0>,  /* D10 */
			   <11 0 &gpio1 1 0>,  /* D11 / SPI-MOSI */
			   <12 0 &gpio1 8 0>,  /* D12 / SPI-MISO */
			   <13 0 &gpio0 13 0>, /* D13 / SPI-SCK */
			   <14 0 &gpio0 4 0>,  /* D14 / A0 */
			   <15 0 &gpio0 5 0>,  /* D15 / A1 */
			   <16 0 &gpio0 30 0>, /* D16 / A2 */
			   <17 0 &gpio0 29 0>, /* D17 / A3 */
			   <18 0 &gpio0 14 0>, /* D18 / A4 / I2C-SDA */
			   <19 0 &gpio0 15 0>, /* D19 / A5 / I2C-SCL */
			   <20 0 &gpio0 28 0>, /* D20 / A6 */
			   <21 0 &gpio1 3 0>;  /* D21 / A7 */

First issue: I believe most of the other connector setups have the first 6 be the A0-A5 not sure if this should be done here?
Second: can/should we just override it within the overlay file for now:

Pins I think need changing: 7, 8, 18, 19, 21

		gpio-map = <0 0 &gpio1 3 0>,   /* D0 / UART-TX */
			   <1 0 &gpio1 10 0>,  /* D1 / UART-RX */
			   <2 0 &gpio1 11 0>,  /* D2 */
			   <3 0 &gpio1 12 0>,  /* D3 */
			   <4 0 &gpio1 15 0>,  /* D4 */
			   <5 0 &gpio1 13 0>,  /* D5 */
			   <6 0 &gpio1 14 0>,  /* D6 */
			   <7 0 &gpio0 23 0>,   /* D7 */
			   <8 0 &gpio0 21 0>,  /* D8 */
			   <9 0 &gpio0 27 0>,  /* D9 */
			   <10 0 &gpio1 2 0>,  /* D10 */
			   <11 0 &gpio1 1 0>,  /* D11 / SPI-MOSI */
			   <12 0 &gpio1 8 0>,  /* D12 / SPI-MISO */
			   <13 0 &gpio0 13 0>, /* D13 / SPI-SCK */
			   <14 0 &gpio0 4 0>,  /* D14 / A0 */
			   <15 0 &gpio0 5 0>,  /* D15 / A1 */
			   <16 0 &gpio0 30 0>, /* D16 / A2 */
			   <17 0 &gpio0 29 0>, /* D17 / A3 */
			   <18 0 &gpio0 31 0>, /* D18 / A4 / I2C-SDA */
			   <19 0 &gpio0 2 0>, /* D19 / A5 / I2C-SCL */
			   <20 0 &gpio0 28 0>, /* D20 / A6 */
			   <21 0 &gpio0 3 0>;  /* D21 / A7 */

Next up to see if I can actually override it within the overlay...

Additional context
Tried with both BLE Sense V2, and a BLE V1

[KurtE]

Quick note:
I tried updating the table in the .overlay file and it fixed most of the pins:
Note: 0, 1, and 18, 19 still don't work, with the simple sketch to blink any pin:

int blink_pin = 2;

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  for (uint8_t i=0; i < 4; i++) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(100);
    digitalWrite(LED_BUILTIN, LOW);
    delay(100);
  }
  pinMode(LED_BUILTIN, INPUT);
  Serial.begin(115200);
  while (!Serial) {}
  Serial.println("Quick blink pin test");
  Serial.println (blink_pin);
  pinMode(blink_pin, OUTPUT);
  Serial.print("LED_BUILTIN: ");
  Serial.println(LED_BUILTIN);
}

void loop() {
  digitalWrite(blink_pin, HIGH);
  delay(250);
  digitalWrite(blink_pin, LOW);
  delay(250);
  if (Serial.available()) {
    int new_pin = Serial.parseInt();
    while (Serial.read() != -1) {
      pinMode(blink_pin, INPUT);
      blink_pin = new_pin;
      pinMode(blink_pin, OUTPUT);
      Serial.print("New pin: ");
      Serial.println(blink_pin);
    }
  }
}

So I then tried to update the connectors file directly: rebuild: ./extras/build.sh ...
burn bootloader, rebuild sketch and same results.

I am assuming that pins 0, 1, don't work as for kernel debug output. Although as far as I can tell, we never get input from the
Serial1 object...

For pins 18, 19 (SCL, SDA) I am guessing that Wire object (arduino_i2c: &i2c0 { ) is somehow holding these pins HIGH? Will look more. But that brings
me back to another question:

When should things go into Zephyr and when should things to into Arduino Core, or when should they simply be normal Arduino libraries?

For example, with the Camera support #41 once this is merged and I rebuild the loader, does that imply all of the sketches
that I build will have camera support built in, in this case for the GC2145, and all of the hardware needed by the camera, such as IO pins, memory, etc. will pre-allocated for use by the camera?

Sorry, I know this is off topic for this issue. But I am still very curious...

[mjs513]

For example, with the Camera support #41 once this is merged and I rebuild the loader, does that imply all of the sketches
that I build will have camera support built in, in this case for the GC2145, and all of the hardware needed by the camera, such as IO pins, memory, etc. will pre-allocated for use by the camera?

Good question. If this is the case would we then have to add in on board devices for Nano 33 ble sense for i2c like for the gc2145? and then the question is what about the other supported camera's?

[facchinm]

For the pins being stuck due to a pre-selected mux, it's indeed an issue with the zephyr way of doing things ™ , but we are actively working with the community to get a more Arduinish way to start/stop the peripherals (you can follow the discussion here zephyrproject-rtos/zephyr#84394 )
Same applies for the camera; at the time being, when we'll merge #41, pin 57 on the Giga will start clocking at 12mhz even if the camera library is not instantiated; this will be fixed exactly in the same way (by the "device init/deinit" patch)

[KurtE]

As @mjs513 mentioned, should we for the BLE 33 Sense, be trying to add all of the code for the sensors, like:
HS3003, BMM150, BM1270), i.e. the ones on Wire1 into the zephyr device tree, or simply handle them the same way
as you would do with MBED version and if your code is interested it would load the library for the specific device(s)?

@facchinm - but back to this issue:
Which way should I try to fix the connector pin mapping?
In zephyr project (.dtsi file) or in ArduinoCore-zephyr project with the .overlay file?

And should we leave the file with the same ordering with the current stuff:
Updated pins:

	arduino_nano_header: connector {
		compatible = "arduino-nano-header-r3";
		#gpio-cells = <2>;
		gpio-map-mask = <0xffffffff 0xffffffc0>;
		gpio-map-pass-thru = <0 0x3f>;
		gpio-map = <0 0 &gpio1 3 0>,   /* D0 / UART-TX */
			   <1 0 &gpio1 10 0>,  /* D1 / UART-RX */
			   <2 0 &gpio1 11 0>,  /* D2 */
			   <3 0 &gpio1 12 0>,  /* D3 */
			   <4 0 &gpio1 15 0>,  /* D4 */
			   <5 0 &gpio1 13 0>,  /* D5 */
			   <6 0 &gpio1 14 0>,  /* D6 */
			   <7 0 &gpio0 23 0>,   /* D7 */
			   <8 0 &gpio0 21 0>,  /* D8 */
			   <9 0 &gpio0 27 0>,  /* D9 */
			   <10 0 &gpio1 2 0>,  /* D10 */
			   <11 0 &gpio1 1 0>,  /* D11 / SPI-MOSI */
			   <12 0 &gpio1 8 0>,  /* D12 / SPI-MISO */
			   <13 0 &gpio0 13 0>, /* D13 / SPI-SCK */
			   <14 0 &gpio0 4 0>,  /* D14 / A0 */
			   <15 0 &gpio0 5 0>,  /* D15 / A1 */
			   <16 0 &gpio0 30 0>, /* D16 / A2 */
			   <17 0 &gpio0 29 0>, /* D17 / A3 */
			   <18 0 &gpio0 31 0>, /* D18 / A4 / I2C-SDA */
			   <19 0 &gpio0 2 0>, /* D19 / A5 / I2C-SCL */
			   <20 0 &gpio0 28 0>, /* D20 / A6 */
			   <21 0 &gpio0 3 0>;  /* D21 / A7 */

Or should it be ordered like the GIGA?

		gpio-map = < 0 0 &gpioc 4  0>,	/* A0 */
			   < 1 0 &gpioc 5  0>,	/* A1 */
			   < 2 0 &gpiob 0  0>,	/* A2 */
			   < 3 0 &gpiob 1  0>,	/* A3 */
			   < 4 0 &gpioc 3  0>,	/* A4 */
			   < 5 0 &gpioc 2  0>,	/* A5 */
			   < 6 0 &gpiob 7  0>,	/* D0 */
			   < 7 0 &gpioa 9  0>,	/* D1 */
			   < 8 0 &gpioa 3  0>,	/* D2 */
			   < 9 0 &gpioa 2  0>,	/* D3 */
			   <10 0 &gpioj 8  0>,	/* D4 */
			   <11 0 &gpioa 7  0>,	/* D5 */
			   <12 0 &gpiod 13 0>,	/* D6 */
			   <13 0 &gpiob 4  0>,	/* D7 */
			   <14 0 &gpiob 8  0>,	/* D8 */
			   <15 0 &gpiob 9  0>,	/* D9 */
			   <16 0 &gpiok 1  0>,	/* D10 */
			   <17 0 &gpioj 10 0>,	/* D11 */
			   <18 0 &gpioj 11 0>,	/* D12 */
			   <19 0 &gpioh 6  0>,	/* D13 */
			   <20 0 &gpioh 12 0>,	/* D14 */
			   <21 0 &gpiob 6  0>;	/* D15 */

Where the first 6 pins are the A0-A5?

[facchinm]

I'd prefer it to be fixed in mainline zephyr if the pinmap is plainly wrong.
About the order, historically in zephyr's device tree there are 2 different types of arduino connectors:
compatible = "arduino-nano-header-r3"; and compatible = "arduino-header-r3";
The first one has the pins in the correct order (D0->D13, then A0 ->A7), while the other has (A0 ->A5->D0->D13), which is "wrong" for our specifications and for this reason is remapped in the overlay

[KurtE]

Thanks, will setup a PR for zephyr...

Sorry, some of this stuff is new to me..
Which fork/branch?
First guess:
https://github.com/facchinm/zephyr/tree/plin_4.0.99

Update: probably:
https://github.com/arduino/zephyr/tree/plin_4.0.99

Also, should it also include: making the build closer to MBED in where the PWR led is turned on?
board.c:
return gpio_pin_configure_dt(&user_led, GPIO_OUTPUT_HIGH);

[KurtE]

Probably wrong place ;) but
arduino/zephyr#2

[facchinm]

@KurtE I think the right place to submit the patch is actually https://github.com/zephyrproject-rtos/zephyr , so all upstream users can benefit from the change (the plan is to get rid of https://github.com/arduino/zephyr/ as soon as all our specific patches are merged)

[KurtE]

Thanks:
zephyrproject-rtos/zephyr#84675

[facchinm]

Manually merged zephyrproject-rtos/zephyr#84675 in https://github.com/arduino/zephyr/