Testing the RGB LED only glows Blue LED with the pinMode declaration from RED

Official Hardware Nano Family Nano 33 BLE
1

Just got my Nano 33 BLE. I was testing some basic things before moving onto sensors and BLE. However I am not able to run even the RGB LED (the simple blinking of LED at pin 13 works fine). According to the schematic/layout it looks like the pin for RED LED is 24, BLUE is 6 and GREEN is 16. However when I run all 3 of them then only BLUE glows. To debug I tried blinking only one of them at a time. For RED, it blinked BLUE. For GREEN and BLUE it permanently glowed BLUE (no blinking).
Then I removed the pinMode definitions for BLUE and GREEN and commented the blinking code of BLUE, GREEN as well as RED. This time the BLUE LED glowed without blinking.
Conclusion:
pinMode(RED, OUTPUT) makes the BLUE LED glow even without calling digitalWrite()

And the other two LEDs don't glow at all.

Any idea what is happening and why is it hapenning?

Following is the simple code snippet -

void setup() {
  #define LED 13
  #define RED 24
  #define BLUE 6
  #define GREEN 16
  
  pinMode(LED, OUTPUT);
  pinMode(RED, OUTPUT);
  pinMode(BLUE, OUTPUT);
  pinMode(GREEN, OUTPUT);
}

void loop() {
  digitalWrite(LED, HIGH);   
  delay(500);                      
  digitalWrite(LED, LOW);   
  delay(50);                      
  digitalWrite(RED, LOW);
  delay(200);
  digitalWrite(BLUE, LOW);
  delay(200);
  digitalWrite(GREEN, LOW);
  delay(200);
  digitalWrite(GREEN, HIGH);
  delay(100);
  digitalWrite(BLUE, HIGH);
  delay(100);
  digitalWrite(RED, HIGH);
  delay(100);
}
2

John_Conrad:
According to the schematic/layout it looks like the pin for RED LED is 24, BLUE is 6 and GREEN is 16.

This is incorrect. The numbers you're looking at are part of manufacturer specified pin identifiers that you would use with low level code. These are different from the Arduino pin numbers you must use with Arduino IO functions like pinMode() and digitalWrite(). Arduino pin numbers are arbitrarily assigned and don't necessarily have any correlation to the pin identifiers you're looking at on the schematic.

From looking at the Nano 33 BLE's variant file:

#define PIN_LED     (13u)
#define LED_BUILTIN PIN_LED
#define LEDR        (22u)
#define LEDG        (23u)
#define LEDB        (24u)
#define LED_PWR     (25u)

It looks like the red LED is on pin 22, the green on 23, and the blue on 24. This is consistent with what you observed.

Another awesome thing you can infer from the code above is that you can control the power LED from your sketch!

It's unfortunate that none of this information has been documented clearly yet. However, the board has only just come out so it's expected that there is some catch up time before the support gets fully polished. Hopefully they'll get that done soon.

3

You are indeed right. Yesterday i was able to get the correct pin values by this experiment-

  for (int i = 0; i<=26; i++){
    pinMode(i, OUTPUT);
    Serial.println(i);
    digitalWrite(i, 0);
    delay(1000);
    digitalWrite(i, 1);
    
   }

As far as the pinMode issue goes , I was able to solve that by using digitalWrite(pin, 1) right below the pinMode initializations for the RGB pins.

I must thank you a lot for pointing me towards the core files....they were much needed.

I have one more question though, since i will be experimenting with board i wished to contribute these details towards the official documentation so that people don't get stuck like i did. How do you reckon i contribute to the official docs and (or) elsewhere?

4

Great work on experimentally determining the pins! I'm glad if I was able to be of assistance after all.

Thanks so much for your interest in contributing to Arduino's documentation. The contribution method is different from one documentation section to another. In the case of the Arduino Store documentation content, you can't contribute directly to the content because the source is not hosted publicly. So the method is to open an issue report in the arduino/Arduino repository. In addition to hosting the Arduino IDE code, that repository acts as a "catch all" for issue reports that don't fit in with any of Arduino's other repositories:

Please do a search of the existing open and closed issue reports before submitting one to be sure it hasn't already been reported. In this particular case, I already did a search and determined there is no existing issue report so you're good to go. I've found that I can increase the chances of my suggested change being made without too much delay and the way I think is best by providing the specific text that I recommend to add/replace in my issue report. That way, the Arduino developer only needs to confirm the suggestion is beneficial and then do a copy/paste to resolve the issue. I should warn you that sometimes the documentation-related issues can take a really long time to be dealt with. On the other hand, there have been times when my suggested change was implemented in less than 24 hours. Either way, I'm confident these issue reports are a very valuable contribution to the Arduino project and that they will all be dealt with eventually.

When I have a suggestion for the documentation of a library, my approach has generally been to submit it as an issue report to the library's repository. They are mostly hosted under this GitHub organization:

In addition to this categorizing the issues more neatly than throwing then all in on the pile with the other 986 open issues in the arduino/Arduino repository, Arduino has a plan to eventually host each library's documentation in that library's repository. On the other hand, I have noticed that the documentation team doesn't appear to closely monitor the library repositories so it might be that submitting the issues there will make it even less likely to be quickly implemented.

There are some other opportunities to collaborate on certain parts of the Arduino documentation in a much more efficient and effective manner. All the Arduino Language Reference content is hosted on GitHub and there is a wonderful system where any changes to that content are automatically synced to this website. So you can simply submit a pull request to the repository with the exact changes you want made. There is a tutorial for this here:
https://create.arduino.cc/projecthub/Arduino_Genuino/contribute-to-the-arduino-reference-af7c37
and the repository is here:

You are also welcome to open issue reports there if you don't want to make a pull request.

To make things even more awesome, there is a system in place to make it very easy for the community to contribute translations of the Arduino Language Content to all non-english languages. You can find the existing translation repositories here:

If you want to help with the translation to a language that doesn't have an existing repository, please open an issue report at arduino/reference-en and we'll get that set up.

I'm one of the maintainers of the arduino/reference-en as well as some of the translation repositories. I try to be very responsive to pull requests and will usually merge non-controversial pull requests within a couple of days. If people open issue reports suggesting improvements that are withing my capabilities to implement, I'll submit a pull request to do so.

Speaking of translations, there is also an initiative to translate the strings of the Arduino IDE's user interface to all languages. There is a nice system that makes it easy for people to contribute translations to this effort:

If you have any questions about this, feel free to contact me. I'm passionate about helping community members get started with contributing to the Arduino project.

5

I put the blink sketch through the Nano 33 BLE and found the LEDR, LEDG, and LEDB are LOW triggers. While the LED_BUILTIN and LED_PWR are HIGH trigger.

void loop() {
 digitalWrite(LED_PWR, HIGH);   
 delay(1000);                       
 digitalWrite(LED_PWR, LOW);    
 delay(200); 
}

That's probably what the "u" in (23u) stands for.

6

logwagon:
That's probably what the "u" in (23u) stands for.

"u" just specifies to the compiler that the number is unsigned.

7

Unassigned? As in 23 is not assigned to a digital output pin?

8

No. Unsigned, not unassigned. It tells the compiler to treat the number as an unsigned int:

9

Ah. Roger that. The screen on my iMac is cracked and the word in question was partially obscured. "Unassigned" seemed reasonable so I didn't think to peek under the little spiderweb.

Thank you for your understanding.

J

10

@pert I started collecting my experiments / docs /know-hows on my repository which also has a Project page here. Eventually I am thinking I will add to the official Arduino docs. What do you say?

11

Looking good John_Conrad!