Initial Portenta C33 testing using 0.3.0

[mjs513]

Not sure you want individual issues but this is what I am seeing so far.

Blink:
Hangs Serial in debug and standard modes. Nothing on Serial1

Thread_Create:
Looses Serial with following error on Serial1 in debug or standard mode:

[00:00:35.704,000] <err> usbd_cdc_acm: IRQ callback is not set

I2C:
Scanner works but keep seeing error on Serial1

[00:00:28.439,000] <err> renesas_ra_iic: i2c_ra_iic_transfer: Write failed.

Ran the BMI270 sparkfun library on wire and that seems to be working no issue. Not seeing the spew which is good.

SPI:
Not implemented yet

Note: keep having to put it into boot mode to load a sketch but maybe thats just the previous sketch that is being run.

[facchinm]

The problem reported as

keep having to put it into boot mode to load a sketch but maybe thats just the previous sketch that is being run.

is related to the missing hook for 1200bps touch on USB_DEVICE_NEXT devices (for now, only the C33).

I2C problem is very likely due to the not found addresses during scan()

WIll take a look at the other issues in the next days

[KurtE]

is related to the missing hook for 1200bps touch on USB_DEVICE_NEXT devices (for now, only the C33).

I was curious about this, so took a look at it. If my quick look at the MBED sources is correct, most
of the Renesas boards (except UNO R4 Wifi), do not use the 1200 touch.
That is in boards.txt they have:
portenta_c33.upload.use_1200bps_touch=false
Also in the SerialUSB.cpp file (MBED), I see:

static void CheckSerialReset() {
    #if NO_1200_BPS_RESET
        return;
    #endif

    if ((_SerialUSB::_bps == 1200) && (! _SerialUSB::_dtr)) {
        goBootloader();
    }
}

So I am guessing maybe it just uses DTR to reboot? Or other mechanism?

Looking through zephyr code (and forum posts), I don't believe there is any callbacks for when DTR changes
state. Wondering if we can emulate it with 12000bbs hook on zephyr... will give it a try.

[facchinm]

On the Renesas core we use dfu-runtime infrastructure to trigger the reset 😉
For this core, the old stack had a callback (that we implement here ) but it looks like there's no equivalent on the NEXT stack

[KurtE]

Thanks, it looked like you have the 1200... hook defined in the variant.cpp file. And I put in printk statement into
it which is not getting set.

I noticed in the config fies, that most of the others had the .conf file define of:
CONFIG_USB_CDC_ACM=y
But the C33 has instead:
CONFIG_USBD_CDC_ACM_CLASS=y
So then wondering if there is a code path difference(s) in the zephyr or modules where either we are not receiving the message or the processing is different and does not call the callback...

EDIT: When I do try to program the C33, there is a 1200 BPS
SET_LINE_CODING message received from the C33 in the function
usbd_cdc_acm_ctd which is in zephyr/subsystem/usb/device_next/class/usbd_cdc_acm.c

I added the printk:

	case SET_LINE_CODING:
		len = sizeof(data->line_coding);
		if (setup->wLength != len) {
			errno = -ENOTSUP;
			return 0;
		}
		printk("usbd_cdc_acm_ctd: SET_LINE_CODING: %u\n", *((uint32_t *)buf->data));
		memcpy(&data->line_coding, buf->data, len);
		cdc_acm_update_uart_cfg(data);
		usbd_msg_pub_device(uds_ctx, USBD_MSG_CDC_ACM_LINE_CODING, dev);
		return 0;

And I am seeing:

*** Booting Zephyr OS build v4.1.0-901-g666b48e54479 ***
usbd_cdc_acm_ctd: SET_LINE_CODING: 9600
usbd_cdc_acm_ctd: SET_LINE_CODING: 115200
usbd_cdc_acm_ctd: SET_LINE_CODING: 1200
usbd_cdc_acm_ctd: SET_LINE_CODING: 115200
uart:~$

And as I suspected, I am not seeing those message from Portenta H7 build.

[KurtE]

More updates on trying to get SerialX to work.

I have a hacked up version of the SerialPassthrough example sketch, where I am also printing up some start up data...

/*
  SerialPassthrough sketch

  Some boards, like the Arduino 101, the MKR1000, Zero, or the Micro, have one
  hardware serial port attached to Digital pins 0-1, and a separate USB serial
  port attached to the IDE Serial Monitor. This means that the "serial
  passthrough" which is possible with the Arduino UNO (commonly used to interact
  with devices/shields that require configuration via serial AT commands) will
  not work by default.

  This sketch allows you to emulate the serial passthrough behaviour. Any text
  you type in the IDE Serial monitor will be written out to the serial port on
  Digital pins 0 and 1, and vice-versa.

  On the 101, MKR1000, Zero, and Micro, "Serial" refers to the USB Serial port
  attached to the Serial Monitor, and "SerialX" refers to the hardware serial
  port attached to pins 0 and 1. This sketch will emulate Serial passthrough
  using those two Serial ports on the boards mentioned above, but you can change
  these names to connect any two serial ports on a board that has multiple ports.

  created 23 May 2016
  by Erik Nyquist

  https://docs.arduino.cc/built-in-examples/communication/SerialPassthrough/
*/
#define SerialX Serial4
void setup() {
  Serial.begin(9600);
  while (!Serial && millis() < 4000) {}
  print_debug_info();

  SerialX.begin(9600);
}

void loop() {
  if (Serial.available()) {        // If anything comes in Serial (USB),
    SerialX.write(Serial.read());  // read it and send it out SerialX (pins 0 & 1)
  }

  if (SerialX.available()) {       // If anything comes in SerialX (pins 0 & 1)
    Serial.write(SerialX.read());  // read it and send it out Serial (USB)
  }
}

void print_debug_info() {
  Serial.println("Print Port/Pin Function Select");
  for (int port_index = 0; port_index < 16; port_index++) {
    Serial.print("Port");
    Serial.print(port_index, HEX);
    Serial.print(": ");
    for (int pin_index = 0; pin_index < 16; pin_index++) {
      Serial.print(" ");
      Serial.print(R_PFS->PORT[port_index].PIN[pin_index].PmnPFS >> 24);
    }
    Serial.println();
  }

  print_SCI_info(0, R_SCI0);
  print_SCI_info(1, R_SCI1);
  print_SCI_info(2, R_SCI2);
  print_SCI_info(3, R_SCI3);
  print_SCI_info(4, R_SCI4);
  print_SCI_info(5, R_SCI5);
  print_SCI_info(6, R_SCI6);
  print_SCI_info(7, R_SCI7);
  print_SCI_info(8, R_SCI8);
  print_SCI_info(9, R_SCI9);
  Serial.println("IELSR registers:");
  //for (uint32_t i = 0U; i < (BSP_ICU_VECTOR_MAX_ENTRIES - BSP_FEATURE_ICU_FIXED_IELSR_COUNT); i++) {
  for (uint32_t i = 0U; i < (sizeof(R_ICU->IELSR_b)/ sizeof(R_ICU->IELSR_b[0])); i++) {
    Serial.print(i);
    Serial.print(R_ICU->IELSR_b[i].IR ? "*0x" : ":0x");
    Serial.print(R_ICU->IELSR_b[i].IELS, HEX);
    if ((i & 0xf) == 0xf) Serial.println();
    else Serial.print(" ");
  }
  Serial.println();
}

void print_SCI_info(uint8_t index, R_SCI0_Type *psci) {
  Serial.print("SCI");
  Serial.print(index);
  Serial.print(": SMR:");
  Serial.print(psci->SMR, HEX);
  Serial.print(" SCR:");
  Serial.print(psci->SCR, HEX);
  Serial.print(" SSR:");
  uint8_t ssr = psci->SSR;
  Serial.print(ssr, HEX);
  // try clearing out some of the status...
  if (ssr & 0x38) {
    //psci->SSR = ssr & ~(0x38);
    Serial.write('*');
  }
  Serial.print(" SEMR:");
  Serial.print(psci->SEMR, HEX);
  Serial.print(" SPTR:");
  Serial.print(psci->SPTR, HEX);
  Serial.print(" SCMR:");
  Serial.print(psci->SCMR, HEX);
  Serial.print(" FCR:");
  Serial.print(psci->FCR, HEX);

  Serial.print(" CR:");
  Serial.print(psci->CR0, HEX);
  Serial.print(" ");
  Serial.print(psci->CR0, HEX);
  Serial.print(" ");
  Serial.print(psci->CR0, HEX);
  Serial.print(" ");
  Serial.print(psci->CR0, HEX);
  Serial.println();
}

I am still having issues with Serial2... Have not tried Serial1 as being used as console
window.

But today I have had success talking to Serial3 and Serial4. Will check Serial2 again.
(Moved it over to breakout board was using Hat carrier.

On Serial2, it was hanging in the low level module. R_SCI_UART_Open right after the interrupts were
enabled.

Output from it is:

*** Booting Zephyr OS build v4.1.0-901-g666b48e54479 ***
usbd_cdc_acm_ctd: SET_LINE_CODING: 9600
usbd_cdc_acm_ctd: SET_LINE_CODING: 115200
uart_ra_sci_configure: 0x4bde0 0x20054760 0x20001998
apply_config err:0
first time try not close first
R_SCI_UART_Open(0x2000199c 0x200019d4) Enter
p_extend(0x200019f4): 0x20001a08 0 0 0
before RX enable 28 31
before TX enable:29 30
Bef

The registers and the like printed:

Print Port/Pin Function Select
Port0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Port1: 6 6 6 6 6 3 0 0 0 0 5 0 0 0 0 0
Port2: 0 0 0 0 0 0 0 0 0 0 0 23 0 0 23 0
Port3: 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0
Port4: 0 0 0 0 5 23 23 19 0 0 0 0 0 0 0 0
Port5: 5 19 4 4 0 0 4 0 5 0 0 7 7 5 0 0
Port6: 3 3 5 5 5 0 4 4 0 0 0 5 0 5 5 0
Port7: 23 23 23 23 23 23 0 20 0 0 0 0 0 0 0 0
Port8: 0 4 0 0 0 5 0 0 0 0 0 0 0 0 0 0
Port9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortA: 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortB: 20 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortC: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortD: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PortF: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
SCI0: SMR:0 SCR:0 SSR:0 SEMR:0 SPTR:0 SCMR:0 FCR:0 CR:0 0 0 0
SCI1: SMR:0 SCR:0 SSR:0 SEMR:0 SPTR:0 SCMR:0 FCR:0 CR:0 0 0 0
SCI2: SMR:0 SCR:0 SSR:0 SEMR:0 SPTR:0 SCMR:0 FCR:0 CR:0 0 0 0
SCI3: SMR:0 SCR:B4 SSR:C4 SEMR:20 SPTR:3 SCMR:FA FCR:F800 CR:0 0 0 0
SCI4: SMR:0 SCR:0 SSR:0 SEMR:0 SPTR:0 SCMR:0 FCR:0 CR:0 0 0 0
SCI5: SMR:0 SCR:70 SSR:92* SEMR:44 SPTR:6 SCMR:F2 FCR:F801 CR:0 0 0 0
SCI6: SMR:0 SCR:70 SSR:92* SEMR:44 SPTR:6 SCMR:F2 FCR:F801 CR:0 0 0 0
SCI7: SMR:0 SCR:70 SSR:92* SEMR:44 SPTR:6 SCMR:F2 FCR:F801 CR:0 0 0 0
SCI8: SMR:0 SCR:70 SSR:92* SEMR:44 SPTR:6 SCMR:F2 FCR:F801 CR:0 0 0 0
SCI9: SMR:0 SCR:70 SSR:84 SEMR:44 SPTR:7 SCMR:F2 FCR:F801 CR:0 0 0 0
IELSR registers:
0:0x6D 1:0x6E 2:0x6B 3:0x6C 40x17F 5:0x17D 6:0x17E 7:0x31 8:0x30 9:0x193 10:0x194 11:0x0 12:0x0 13:0x0 14:0x0 15:0x0
16:0x0 17:0x0 18:0x0 19:0x0 20:0x19E 21:0x19F 22:0x1A0 230x1A1 24:0x1A4 25:0x1A5 26:0x1A6 270x1A7 28:0x1AA 29:0x1AB 30:0x1AC 310x1AD
32:0x1B0 33:0x1B1 34:0x1B2 35*0x1B3 36:0x0 37:0x0 38:0x0 39:0x0 40:0x0 41:0xA 42:0xB 43:0x0 44:0x0 45:0x0 46:0x0 47:0x0
48:0x0 49:0x31 50:0x30 51:0x16F 52:0x0 53:0x0 54:0x17F 55:0x0 56:0x0 57:0x0 58:0x0 59:0x0 60:0x0 61:0x0 62:0x0 63:0x0
64:0x0 65:0x0 66:0x0 67:0x0 68:0x0 69:0x0 70:0x0 71:0x0 72:0x0 73:0x0 74:0x1B6 75:0x1B7 76:0x1B8 77:0x1B9 78:0x0 79:0x0
80:0x0 81:0x0 82:0x0 83:0x0 84:0x0 85:0x0 86:0x0 87:0x0 88:0x0 89:0x0 90:0x0 91:0x78 92:0x79 93:0x7A 94:0x7B 95:0x0

So the interrupts it tried to enable: 28-31
Which the ISR table, which shows the events for these are:
`28:0x1AA 29:0x1AB 30:0x1AC 31*0x1AD
`

Now back to debugging:

Note: I am using: 

Zephyr:
https://github.com/KurtE/zephyr/tree/c33_wifi_sf_rebased_sci6
Which is based on facchinm branch c33_wifi_sf_rebased where I cherry picked my change
to fix SCI6.  -> I have PR back to ...

ArduinoCore-zephyr:
https://github.com/KurtE/ArduinoCore-zephyr/tree/Portenta_C33_add_Pins_plus

[KurtE]

Update: Serial2 appears to be working as well. Wonder if Serial1 and 2 are reversed in my list... That is the debug actually goes out on Serial2?

Thought I would see how it all works with each other, so I did a quick and dirty update to one of the tests I
have done on Teensy boards, while I worked on the Serial code and later with the UNOR4, with the rewrite PR that was never integrated... Simply Daisy chain the TX of one Serial port to the RX of another... and see if all of them get all of the data...

//connect  Serial1 TX -> Serial2 RX, Serial2 TX -> Serial3 RX, Serial3 TX -> Serial4 RX....

#define SPD 115200
int loop_count = 0;

#define BUFFER_SIZE 80

class BufferInfoClass {
public:
  BufferInfoClass() {
    clear();
  }
  char buffer[BUFFER_SIZE];
  uint8_t cb_buffer;
  uint8_t cb_copy[BUFFER_SIZE];
  uint8_t cb_copy_cnt;
  void clear() {
    cb_buffer = 0;
    cb_copy_cnt = 0;
  }
};

BufferInfoClass buffers[4];
uint32_t millis_last_input = 0;

void setup() {
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);
  pinMode(8, OUTPUT);
  pinMode(LED_BUILTIN, OUTPUT);
  while (!Serial && millis() < 4000)
    ;
  Serial.begin(115200);
  delay(800);
  Serial.println("Test all Serials");
  Serial.print("Baud rate: ");
  Serial.println(SPD, DEC);
  Serial2.begin(SPD);
  Serial3.begin(SPD);
  Serial4.begin(SPD);
}

#define MIN(a, b) ((a) <= (b) ? (a) : (b))


void CopyFromTo(Stream &SerialF, Stream &SerialT, uint8_t buffer_index) {
  int available;
  int available_for_write;
  int cb;
  BufferInfoClass *buf = &buffers[buffer_index];
  if ((available = SerialF.available()) != 0) {
    available_for_write = SerialT.availableForWrite();
    cb = MIN(MIN(available, available_for_write), BUFFER_SIZE);
    if (cb) {
      SerialF.readBytes(&buf->buffer[buf->cb_buffer], cb);
      SerialT.write(&buf->buffer[buf->cb_buffer], cb);
      buf->cb_buffer += cb;
      buf->cb_copy[buf->cb_copy_cnt] = cb;
      buf->cb_copy_cnt++;
      millis_last_input = millis();
    }
  }
}

void memory_dump(const char *pb, uint8_t cb) {
  const char* pbA = pb;
  uint8_t cbA = cb;

  Serial.print("\t");
  for (uint8_t i = 0; i < cb; i++) {
    if (*pb < 0x10) Serial.write('0');
    Serial.print(*pb, HEX);
    Serial.print(" ");
    pb++;
  }
  
  Serial.print("\n\t ");
  for (uint8_t i = 0; i < cbA; i++) {
    if (*pbA >= ' ')  Serial.write(*pbA);
    else Serial.write(' ');
    Serial.print("  ");
    pbA++;
  }
  Serial.println();
}

void print_buffer_header(uint8_t index) {
  BufferInfoClass *buf = &buffers[index];
  Serial.print("  ");
  Serial.print(buf->cb_buffer, DEC);
  Serial.print(" (");
  for (uint8_t i = 0; i < buf->cb_copy_cnt; i++) {
    if (i != 0) Serial.print(",");
    Serial.print(buf->cb_copy[i], DEC);
  }
  Serial.print(")");
}

void CompareBuffers(uint8_t index1, uint8_t index2) {
  if (buffers[index1].cb_buffer == buffers[index2].cb_buffer) {
    if (memcmp(buffers[index1].buffer, buffers[index2].buffer, buffers[index1].cb_buffer) == 0) {
      Serial.println(" ** Match **");
      return;
    } else {
      Serial.println(" ** different **");
    }
  } else {
    Serial.println(" ** counts different **");
  }
  memory_dump(buffers[index1].buffer, buffers[index1].cb_buffer);
  memory_dump(buffers[index2].buffer, buffers[index2].cb_buffer);
}

void loop() {
  CopyFromTo(Serial, Serial2, 0);
  CopyFromTo(Serial2, Serial, 1);
  CopyFromTo(Serial3, Serial3, 2);
  CopyFromTo(Serial4, Serial4, 3);

  // now see if we should compare the data yet or not
  if (buffers[0].cb_buffer && ((millis() - millis_last_input) > 100)) {
    Serial.println("Check buffers: ");

    print_buffer_header(0);
    Serial.println();
    print_buffer_header(1);
    CompareBuffers(0, 1);

    print_buffer_header(2);
    CompareBuffers(0, 2);

    print_buffer_header(3);
    CompareBuffers(0, 3);


    buffers[0].clear();
    buffers[1].clear();
    buffers[2].clear();
    buffers[3].clear();
  }
  digitalWrite(LED_BUILTIN, HIGH);
  delayMicroseconds(100);  // give time form things to propagate
  digitalWrite(LED_BUILTIN, LOW);
}

Short answer looks like it is losing data...

	 
abcdefghijklmnopVWXYZ0123456789
Check buffers: 
  64 (64)
  35 (2,8,8,8,8,1) ** counts different **
	61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	 a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9        
	00 00 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	       a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9        
  33 (16,8,8,1) ** counts different **
	61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	 a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9        
	61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	 a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9        
  35 (2,8,8,8,8,1) ** counts different **
	61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	 a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9        
	00 00 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 56 57 58 59 5A 30 31 32 33 34 35 36 37 38 39 0D 0A 
	       a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  V  W  X  Y  Z  0  1  2  3  4  5  6  7  8  9      

Will check this out later. Already works better than some of the others...

[KurtE]

@facchinm - wondering about code versus schematic for C33 for Serial ports...
That is the Schematic shows:

But the code is setup with the order SCI9, SCI7, SCI6, SCI5?
MBED: from pins_arduino.h

#define UART1_TX_PIN        14
#define UART1_RX_PIN        13
#define UART2_TX_PIN        49
#define UART2_RX_PIN        50
#define UART3_TX_PIN        53
#define UART3_RX_PIN        54
#define UART4_TX_PIN        57
#define UART4_RX_PIN        58
#define UART5_TX_PIN        92
#define UART5_RX_PIN        93
#define UART5_RTS_PIN       94
#define UART5_CTS_PIN       95

From Variant.cpp

  { BSP_IO_PORT_01_PIN_10,  P110 }, /*   D13    |  RX0        */
  { BSP_IO_PORT_06_PIN_02,  P602 }, /*   D14    |  TX0        */
...
 // UART pins
  { BSP_IO_PORT_06_PIN_13,  P613 }, /*   D49    |   TX2    */
  { BSP_IO_PORT_06_PIN_14,  P614 }, /*   D50    |   RX2    */
  { BSP_IO_PORT_06_PIN_11,  P611 }, /*   D51    |   RTS2   */
  { BSP_IO_PORT_04_PIN_04,  P404 }, /*   D52    |   CTS2   */
  { BSP_IO_PORT_05_PIN_06,  P506 }, /*   D53    |   TX3    */
  { BSP_IO_PORT_03_PIN_04,  P304 }, /*   D54    |   RX3    */
  { BSP_IO_PORT_05_PIN_03,  P503 }, /*   D55    |   RTS3   */
  { BSP_IO_PORT_05_PIN_02,  P502 }, /*   D56    |   CTS3   */
  { BSP_IO_PORT_08_PIN_05,  P805 }, /*   D57    |   TX4    */
  { BSP_IO_PORT_05_PIN_13,  P513 }, /*   D58    |   RX4    */
  { BSP_IO_PORT_05_PIN_08,  P508 }, /*   D59    |   RTS4   */
  { BSP_IO_PORT_05_PIN_05,  P500 }, /*   D60    |   CTS4   */
  { BSP_IO_PORT_06_PIN_03,  P603 }, /*   D61    |   RTS0   */
  { BSP_IO_PORT_06_PIN_04,  P604 }, /*   D62    |   CTS0   */
...
  // ESP32 UART
  { BSP_IO_PORT_10_PIN_00,  PA00 }, /*   D92    |   TX1    */
  { BSP_IO_PORT_06_PIN_07,  P607 }, /*   D93    |   RX1    */

Back to the schematic:

We then map:

Serial1 -> SCI9,
Serial2 -> SCI7,
Serial3 -> SCI6
Serial4 -> SCI5

And the one I have not added yet but MBED: as guessing you might be using the other device tree stuff you added, but could easily
Serial5 -> SCI8

[KurtE]

@facchinm @pillo79 - Sorry for asking lots of questions. I think I may mark my current C33 PR as ready to merge although was looking at the Wire objects. MBED defines 4 of them, whereas we only have one....

Currently on the Zephyr side we only define:
in pin control

	iic1_default: iic1_default {
		group1 {
			/* SCL1 SDA1 */
			psels = <RA_PSEL(RA_PSEL_I2C, 5, 12)>,
			<RA_PSEL(RA_PSEL_I2C, 5, 11)>;
			drive-strength = "medium";
		};
	};

And in the DTS we have

&iic1 {
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;
	interrupts = <91 1>, <92 1>, <93 1>, <94 1>;
	interrupt-names = "rxi", "txi", "tei", "eri";
	clock-frequency = <DT_FREQ_M(1)>;
	pinctrl-0 = <&iic1_default>;
	pinctrl-names = "default";
};

So I was going to define the iic0 object in the overlay...
Simple enough to define the correct pins for it...
But not sure about:
interrupts = <91 1>, <92 1>, <93 1>, <94 1>;
I know it is the Interrupt slot number as my debug code from Serial stuff printed out the table:

ELSR registers:
0:0x6D 1:0x6E 2:0x6B 3:0x6C 4*0x17F 5:0x17D 6:0x17E 7:0x31 8:0x30 9:0x193 10:0x194 11:0x0 12:0x0 13:0x0 14:0x0 15:0x0
16:0x0 17:0x0 18:0x0 19:0x0 20:0x19E 21:0x19F 22:0x1A0 23:0x1A1 24:0x1A4 25:0x1A5 26:0x1A6 27:0x1A7 28:0x1AA 29:0x1AB 30:0x1AC 31:0x1AD
32:0x1B0 33:0x1B1 34:0x1B2 35*0x1B3 36:0x0 37:0x0 38:0x0 39:0x0 40:0x0 41:0xA 42:0xB 43:0x0 44:0x0 45:0x0 46:0x0 47:0x0
48:0x0 49:0x31 50:0x30 51:0x16F 52:0x0 53:0x0 54:0x17F 55:0x0 56:0x0 57:0x0 58:0x0 59:0x0 60:0x0 61:0x0 62:0x0 63:0x0
64:0x0 65:0x0 66:0x0 67:0x0 68:0x0 69:0x0 70:0x0 71:0x0 72:0x0 73:0x0 74:0x1B6 75:0x1B7 76:0x1B8 77:0x1B9 78:0x0 79:0x0
80:0x0 81:0x0 82:0x0 83:0x0 84:0x0 85:0x0 86:0x0 87:0x0 88:0x0 89:0x0 90:0x0 91:0x78 92:0x79 93:0x7A 94:0x7B 95:0x0

And 91-94 have 0x78-0x7B, which from the RM tables I see:

But my guestion is, who decides that slots 91-94 are the proper ones to use? How many others are hard coded? Can the build simply allocate unused ones for this? Or is it done just to make it easy for a library, to not have to look it up?

[KurtE]

Quick update:
I added it to my overlay as I mentioned. Changed 91-94 to 87-90. And now have Wire and WIre1.

Not sure about Wire2 yet as it is SCI2

Also like Serial, not sure about WIre3 yet as it is SCI3 and is internal ...
Like can we mix IIC objects with SCI objects in their object lists...

But looks like it works. I tested it using Sparkfun QWIIC buttons, one on Wire and the other on Wire1. One hook up was
through a board that Paul of PJRC made us several years ago for us to test Wire code on Teensy boards... The other used a
QWIIC break out cable.

Pardon the mess as my table/desk has several different hookups and this one alone has the ones mentioned plus USB to Serial
adapter.