"Nano R4 User Manual" pins don't match schematic?

Official Hardware Nano Family Nano R4
1

I was trying to figure out what PWM pins use what timers, and found the Nano R4 User Manual. It seems like a nice reference.

It has multiple tables that list the Arduino pins and the corresponding RA4M1 pins, but they don’t match the official Nano R4 schematic. It also doesn’t match other versions of the R4 that I looked at. Where do these pin numbers come from?

Nano R4 User Manual:

Arduino Pin Microcontroller Pin
D0 P104
D1 P105
D2 P213
D3 P212
D4 P109
D5 P110
D6 P107
D7 P106
D8 P300
D9 P108
D10 P103
D11 P101
D12 P100
D13 P102

Nano R4 schematic:

D0 P302
D1 P301
D2 P105
D3 P104
D4 P103
D5 P102
D6 P106
D7 P107
D8 P304
D9 P303
D10 P112
D11 P109
D12 P110
D13 P111

2

When in doubt, trust the source that the sketch uses.

extern "C" const PinMuxCfg_t g_pin_cfg[] = {
  { BSP_IO_PORT_03_PIN_01,    P301   }, /* (0) D0  -------------------------  DIGITAL  */
  { BSP_IO_PORT_03_PIN_02,    P302   }, /* (1) D1  */
  { BSP_IO_PORT_01_PIN_05,    P105   }, /* (2) D2  */
  { BSP_IO_PORT_01_PIN_04,    P104   }, /* (3) D3~ */
  { BSP_IO_PORT_01_PIN_03,    P103   }, /* (4) D4  */
  { BSP_IO_PORT_01_PIN_02,    P102   }, /* (5) D5~ */
  { BSP_IO_PORT_01_PIN_06,    P106   }, /* (6) D6~ */
  { BSP_IO_PORT_01_PIN_07,    P107   }, /* (7) D7  */
  { BSP_IO_PORT_03_PIN_04,    P304   }, /* (8) D8  */
  { BSP_IO_PORT_03_PIN_03,    P303   }, /* (9) D9~  */
  { BSP_IO_PORT_01_PIN_12,    P112   }, /* (10) D10~ */
  { BSP_IO_PORT_01_PIN_09,    P109   }, /* (11) D11~ */
  { BSP_IO_PORT_01_PIN_10,    P110   }, /* (12) D12 */
  { BSP_IO_PORT_01_PIN_11,    P111   }, /* (13) D13 */
  { BSP_IO_PORT_00_PIN_14,    P014   }, /* (14) A0  --------------------------  ANALOG  */
  { BSP_IO_PORT_00_PIN_00,    P000   }, /* (15) A1  */
  { BSP_IO_PORT_00_PIN_01,    P001   }, /* (16) A2  */
  { BSP_IO_PORT_00_PIN_02,    P002   }, /* (17) A3  */
  { BSP_IO_PORT_01_PIN_01,    P101   }, /* (18) A4/SDA  */
  { BSP_IO_PORT_01_PIN_00,    P100   }, /* (19) A5/SCL  */
  { BSP_IO_PORT_00_PIN_04,    P004   }, /* (20) A6  */
  { BSP_IO_PORT_00_PIN_03,    P003   }, /* (21) A7  */

  { BSP_IO_PORT_02_PIN_04,    P204   }, /* (22) LED_BUILTIN  */

  { BSP_IO_PORT_04_PIN_09,    P409   }, /* (23) RED LED  */
  { BSP_IO_PORT_04_PIN_10,    P410   }, /* (24) GREEN LED  */
  { BSP_IO_PORT_04_PIN_11,    P411   }, /* (25) BLUE LED  */

  { BSP_IO_PORT_04_PIN_00,    P400   }, /* (26) QWIIK SCL  */
  { BSP_IO_PORT_04_PIN_01,    P401   }, /* (27) QWIIK SDA  */

  { BSP_IO_PORT_05_PIN_00,    P500   }, /* (28) 3V3 enable  */
};
3

Ah, that’s a nice source of truth. Thank you.

I still have to cross reference the datasheet to get the timer channels per pin, whereas the user manual has a (wrong) table of them. It’d be nice if that could get corrected. The bottom of the page points to a GitHub page where you’re supposed to be able to edit the document somehow, but the link is dead. :face_with_diagonal_mouth:

4

Are you maybe confusing the chip connector numbers with the board pin numbers?

5

You mean the pin # of the IC? That could explain things, but the package doesn't have 300 pins. I’ve never seen them with the “p” prefix either.

6

Post 2 is the answer, looking at anything else is just wasting your time.
Here is a mini tutorial.
After a successfull verify (there may be other conditions as well) if you right click on the highlighted arduino_pins.h and select Go to Definition a new ReadOnly tab will open with the pins_arduino.h open in it. This can be different for each board.

add include

ap1
ap1498×114 9.94 KB

AFTER a successful verify you can do this

ap2
ap2712×156 30 KB

and a new READONLY tab will be created with the selected boards pins definitions

my new standard UNO

ap3
ap3808×1072 96.6 KB

my standard DOIT esp32

ap4
ap4694×1042 104 KB

7

Hi @skidlz.

Thanks for bringing this to our attention. I have submitted a report to the people at Arduino responsible for this documentation.

I apologize for any confusion caused by this error.

I've reported this to the documentation team as well.

In case you are interested, the link is supposed to point here:

8

Hi all,

Thanks again for bringing this to our attention. My apologies for the confusion caused by this error. I have updated the microcontroller pins in the board's user manual. It is now corrected on Docs:

Best,

José

9

@ptillisch @van_der_decken Several folks I trust for their knowledge have pointed at what I think are proper locations for the correct documentation while I naively carry on using the

#include <pins_arduino.h>

approach.

Can anyone narrow down what the 'magical' include is that will ALWAYS be correct since it is code. It looks like @van_der_decken has it but HOW did he come up with that and is it different by board.

For me, why is

#include <pins_arduino.h>

not always correct?

10

In general, the pins_arduino.h file in the appropriate variant directory is the way to go. In fact, in many variant directories, it's the only file there.

But in the case of the R4s (and some other cores), there's an extra layer of complexity in variant.cpp to get down to which Pnnn pin is actually being used.

11

I am trying to track down the R4 variant but my sleuthing gene seems to be defected. I have travelled down Library/Arduino15/packages/arduino/hardware and am then faced with these choices

Screenshot 2026-04-29 at 11.01.01
Screenshot 2026-04-29 at 11.01.01386×558 38.2 KB

there is something I am not getting, can you point it out?

12

renesas_uno is the tree you want.

13

Got it. I will have to do some experiments, it would be nice if it could be automated such that no matter what board is used the correct hdrs are pulled in for pin translation. Like I don;t have anything else to do!!!

14

I feel sure that everything in the variant directory does get pulled in as needed, but I admit to treating it as a black box and trusting that it's done properly. :slightly_smiling_face:

The variants with just the pins_arduino.h file in the variant directory are a lot easier to wrap my head around.

15

Yes, those are very straight forward. If/when I haver time I will see what if anything can be done with the others.

16

Do you mean you add that line to a sketch in Arduino IDE and then use the "Go to Definition" feature to open the pins_arduino.h file in an Arduino IDE editor tab?

The Arduino boards platform framework doesn't impose any specific structure on the codebase of the core variant beyond requiring that it be located under a dedicated folder in the variants subfolder of the platform.

The placement of Arduino pin mapping code in a file named pins_arduino.h is only a common convention rather than something mandated by the platform framework.

As @van_der_decken said, in terms of using the resources provided by the core variant in your own code, this is already done.

The sketch build system automatically compiles the source code in the core variant's folder. It is a standard convention for the Arduino.h file in the core to contain an #include directive for pins_arduino.h. For example:

This is done by all official platforms and I'm not aware of any exceptions even in the 3rd party platform ecosystem.

The sketch build system automatically adds an #include directive for Arduino.h to the .ino file of the sketch before compiling the code, so the declarations from pins_arduino.h can be referenced from the code in the .ino file without needing to do anything special due to the transitive #include via Arduino.h.

That sketch preprocessing is exclusive to .ino files, so you do need to add an explicit #include directive in non-.ino source files of a sketch, or in library code. As with the .ino file, this will usually be done via an #include directive for Arduino.h. That approach makes sense because, unlike pins_arduino.h, the Arduino sketch build system does impose a requirement that the core contain an Arduino.h file. So you can treat Arduino.h as the way to obtain declarations of the core API, leaving all the underlying implementation to the whims of the developers of the individual platform.

What I wrote above is specific to utilizing the core variant in your code. If your interest is instead to study the core variant code to gain insights into the low level details of things like pin mapping, then I think the best approach is to open the entire variant folder in a text editor and search around through the various files.

Tangential to the subject of pin mapping, but in regards to understanding the core variant in general, something worth noting is the use of "response files" (@file). For example:

The compilation command templates defined by the platform pass these files as arguments in the invocation, resulting in each of the flags in the file being passed to the compiler. This can be a bit confusing if you are examining the compilation commands that are printed in Arduino IDE's verbose compilation output because you will only see the @file reference in the command, and would only learn what exactly that adds to the command by opening up the referenced file in a text editor to see what it contains.

17

That is great info. I have my model starting sketch set up with
#include <Arduino.h>
and recently added
#include <pins_arduino.h>
because I am curious and slow to learn in my advanced years. If I have to determine whether a pin is named D22 or just 22 going to the definition of the pins is faster than checking the docs.

18

Hi Jose,

Thanks for updating the page. The pins look correct, but the PWM channels don't match what I'm seeing in the header files or the datasheet. This is what I've pieced together for GPT channels per pin:

Arduino Pin RA4M1 Pin GTIO
D1 P301 4B
D0 P302 4A
D2 P105 1A
D3 P104 1B
D4 P103 2A
D5 P102 2B
D6 P106 0B
D7 P107 0A
D8 P304 7A
D9 P303 7B
D10 P112 3B
D11 P109 1A
D12 P110 1B
D13 P111 3A
A0 P014 -
A1 P000 -
A2 P001 -
A3 P002 -
A4 P101 5A
A5 P100 5B
A6 P004 -
A7 P003 -
19

Thank you for the corrections. I totally forgot to update this table before. It is updated now in Docs: https://docs.arduino.cc/tutorials/nano-r4/user-manual/#pwm-pulse-width-modulation

Best,

José