Nano 33 BLE (Rev 2) - Onboard LED Green/Blue Swapped

Hi there!

I recently swapped in a brand new Nano 33 BLE (Rev 2) board to my project in place of one that I previously damaged. I'm uploading one of the most basic sketches imaginable, which flashes the onboard LED a few times during startup and then leaves it set to a particular color. I used to set it to blue on the old board, but when I uploaded the sketch to this new board, it illuminated green! Setting the LED to green instead now makes it light up blue.

I've tried every code verification I can think of for the onboard LED RGB pin constants and it appears that the two pin numbers for the onboard LED green and blue (23 and 24, respectively -- https://support.arduino.cc/hc/en-us/articles/360016724140-Control-the-RGB-LED-on-Nano-33-BLE-boards) are simply behaving swapped in the hardware. LEDR (22) still illuminates the LED red as it should, which is equally puzzling to me given that blue and green are swapped.

To summarize, the behavior seems to go as follows:

digitalWrite(LEDR, LOW) -> Onboard LED illuminates RED
digitalWrite(LEDG, LOW) -> Onboard LED illuminates BLUE
digitalWrite(LEDB, LOW) -> Onboard LED illuminates GREEN

The only modifications I've made to the board are soldering on the included headers and cutting the 3.3V jumper in conjunction with supplying the board from a 3.3V LDO voltage regulator. Below is the sketch that produces a BLUE onboard LED after start-up:

void setup() {

  pinMode(LEDR, OUTPUT);
  pinMode(LEDG, OUTPUT);
  pinMode(LEDB, OUTPUT);
  
  for (int i = 0; i < 5; i++) {
    digitalWrite(LEDR, LOW);
    digitalWrite(LEDG, LOW);
    delay(100);
    digitalWrite(LEDR, HIGH);
    digitalWrite(LEDG, HIGH);
    delay(100);
  }

  long start_millis = millis();
  Serial.begin(9600);
  while (!Serial) {
    if (millis() - start_millis > 5000) {
      break;
    }
    delay(50);
  }

  Serial.print("Started up Woody sensor module (took ");
  Serial.print((millis() - start_millis) / 1000.0);
  Serial.println(" seconds)");

  digitalWrite(22, HIGH);
  digitalWrite(23, HIGH);
  digitalWrite(24, HIGH);

  digitalWrite(LEDG, LOW);

  // digitalWrite(LEDB, LOW);

  analogReadResolution(12);

}

void loop() {

  Serial.println(millis());

  delay(1000);

}

Any ideas as to what could explain this? Could a stray cutting stroke with my utility knife while severing the 3.3V jumper or perhaps some header soldering error (excess / prolonged heat?) possibly lead to this color swap? I would think a mechanical mistake such as that would make either all/none of the pins work (or all 3 would be incorrect), and also that said pins are so internal to the board that they would not be easily swapped like this from some external mistake. Thanks in advance for any thoughts you have!

Best,
Daniel

Green and blue leds swap

What is your question?

Sorry, I guess I’m confused, I must not have phrased my question properly. Is this like a normal manufacturing defect for a board to have the onboard LED pins/colors be incorrect? Does it imply anything else may work improperly too, or am I just supposed to modify all sketches that might run on this particular board to have their LED colors swapped when deployed to this one particular device?

I'd just consider it to be a manufacturing error and leave it at that. Somehow the LEDs got swapped, it doesn't imply anything else is wrong.

Found this article; anybody know if the same issue affects the Nano 33 BLE Rev 2? I have two additional boards that are exhibiting the same problem. >.< FWIW, the RGB LED component looks black vs. green when examining a faulty board...

What are trying to achieve?
Do you expect a refund because of this little thing?

Well, I can get my refunds through Amazon if I need to, and yes I do return the defective boards. At this point three of these “tiny little things” is $75, but if that’s nothing to you, then feel free to send me $75 because I do care about $75.

What am I trying to achieve?

  1. I’d like to know if anybody else has seen the same issue with this board and if there is any possible fix short of returning/scrapping it.

  2. I’d like to understand, for my own knowledge and education, what might cause a board to have this type of malfunction/defect.

  3. I’d like to have a public record of items 1 and 2 so that if/when other confused users encounter the same behavior, they might be able to find some useful information about it somewhere online (apparently this thread is the most informative on this issue, which is a bit depressing given the attitude and lack of information).

    It’s amazing and sad to me the level of snark and condescending attitude I sense on forums like this that are supposed to be about helping educate people on electronics and supposedly encourage new makers/DIYers in their journey… goodness knows this is not the kind of tone that would inspire any happiness, confidence or curiosity in me if I were completely new to Arduino and confused by this objectively confusing behavior. Good day.

The methods to roundabout this are described in the document referred in your post #5 above.

nothing

Don't look for some kind of conspiracy behind this. It's just a minor error in the board layout or they just soldered in an LED with a different pin arrangement.
I think your boards are otherwise completely functional.

Scrapping would of course be silly. It seems to be a fully functional board, but with a minor non-conformance to specification that doesn't impede its usability. This issue can indeed be fixed; for instance, with a hot air soldering station, the blue and green LEDs could be swapped. However, your average Amazon shop will not do this. They will either sell the returned product on to the next customer, or return it to their supplier. Ultimately it may or may not be scrapped, or it may or may not be sold at a discount and/or in a market where end users are less picky.

Again, not every deviation from spec constitutes a malfunction or a defect. Neither is the case here. Two LEDs were apparently swapped and given that both work, the board as such appears to be fully functional. Possible causes for this deviation from spec are:

  • During schematic capture the wrong label was attached to these LEDs. The design error carried through to PCB layout and manufacturing.
  • During PCB layout, it's possible that two nets ended up being swapped, potentially as a result of engineering changes that involve iterating between schematic capture and PCB layout.
  • During manufacture, the reels with the green and the blue LEDs were incorrectly mounted (i.e. swapped) on the pick & place machine. The result would be that every design manufactured in that period would have a green LED where a blue one should have been and vice versa. So in this case, it's possible there's other hardware out there on the planet that has this same issue.

This is indeed one of the useful features of a forum. Thanks for submitting it.

I suspect that the minor impact of this flaw has resulted in a lack of interest in dealing with the issue.

In case you consider scrapping or returning these boards, consider what the impact of doing so is, and whether it's justified in the light of the minor inconvenience of having a blue light in the spot where you expected a green one, and vice versa. There may be a way to learn to come to grips with this, and perhaps to even live with a degree of satisfaction or enjoyment despite this unfortunate turn of events.

1 Like

Your code can very easily be modified so that a green LED lights when green light is intended, and similarly, for blue.

In this complex world, a bit of personal flexibility can help one to compensate for difficulties and challenges that arise.

4 Likes

I'm not going to die of misery if this is not fixed, I'll just keep exchanging the boards until I get working ones. I was just curious if anybody knowledgable on the matter knew why it was happening and/or whether there was a known bad batch of these and/or whether there was a visual identifier that indicated the problem similar to the situation in the Nano ESP32 link.

We'll have to agree to disagree that this issue is problematic and noteworthy. I have been programming for basically my entire life and the idea that I would need to set something like a #define for BOARD_IS_FAULTY to swap all calls to green and blue LED pins, then test every board I need to use for my project for this defect manually and recompile/load alternate programs based on the board's (non-)conformance to its spec, makes me throw up a little in my mouth. Basically the board is not PIN-compatible with itself (depending on the particular faulty or not-faulty unit), which strikes me as very odd given that numerous other components like op-amps seem to often be pin-compatible with different models. Precision matters in electronics, so the fact that these LEDs are routinely miswired on the boards seems like an actual problem to me. Without more robust onboard displays, and in low-power/remote applications (which is exactly what this board seems intended for), some people (myself included) would like to be able to use that RGB LED to indicate different states and conditions on the device. If the colors cannot be relied upon, then a green vs. a blue indication would be ambiguous and make the board's diagnostic LED completely unreliable (unless it had been thoroughly tested and the correct version of the program known to be loaded on there, which is not something I want to have to doubt with every device I deploy).

I think the LED has utility, and I think having the correct R, G and B colors also has significant utility, so if others think this LED and it illuminating the correct color is such a non-issue, why is this LED included on the board in the first place? If it's not important enough to be expected to function reliably, then it shouldn't be a feature of the product at all, because apparently I'm the only one who thinks it's useful and would like to be able to rely on it without jumping through some pretty silly hoops.

For any time-travelers from the future who do also care about this issue, I have discerned some potentially useful information about this. One of my replacement boards I received today does not have the defect, and its LED component is a different color (looks white to my eye, when not illuminated of course). Included is a photo comparing a defective board (left) and a correctly-functioning board (right); notice the LED component above the right side of the NINA-B306 is WHITE in the functioning one and BLACK in the board where green and blue are reversed. So while it's only N = 1, this could be a visual indication of which boards are faulty and which ones are not, similar in principle to the Nano ESP32 article but just with different colors than in that case... black being faulty here, white being properly functional.

And one more data point: my other faulty board (this one "with headers") also has a black LED.

long meaningless messages, excessive attention to detail... are you healthy?

1 Like

Troll identified and ignored.

Ok, so this explains what went wrong quite well, and it's sort of similar to my suggested #3, although not quite. It looks like in manufacturing, for this batch a different type of RGB LED was used than the one specified, with a different pinout.

It's safe to assume that this applies to a fair number of boards. At some point, different batches were manufactured or at least the reel with RGB LEDs was swapped out on the P&P machine.

You have expressed an expectation of exactness and correctness. Consider extending this to your vocabulary. "deviation from spec" does not equal "faulty". Both boards are factually speaking functional. Let's not muddy the waters.

3 Likes

I did not say the board was non-functional (and yes, there is a difference between non-functioning and a malfunction). The boards are, in fact, faulty according to any definition I've found online for "faulty", e.g. the first one returned by Google: "working badly or unreliably because of imperfections." ... honestly it seems like the above quote serves to muddy the waters a lot more than what I've been saying.

The boards with black LEDs are defective / faulty / malfunctioning. They are not completely unusable, nor non-functional. They do, however, work unreliably because of an imperfection.

I really don't understand the level of defensiveness here around labeling these boards faulty (because they are faulty), but please save us all the time and don't keep complaining that I view this as faulty. Yes, I have an expectation of exactness and correctness, and I think that's quite reasonable given the prolific datasheets and specifications for every single electronic component online. I sure wouldn't want to ride in a car built by electrical engineers who didn't care about correctness and exactness. There's a big difference between a green and a blue LED, and there's a big difference between 3.0V and 3.3V and 3.6V. There's a reason that Arduino wrote an entire support article about a bad batch of Nano ESP32 boards with the same problem, and in lieu of a similarly helpful article for the Nano BLE 33 Rev 2, I hope some kind souls in the future find this thread eventually and get their question answered too. I guess I'll just consider myself having taken one for the team on behalf of those of us who are here to learn / educate ourselves and who want to become knowledgeable about a problem with these boards.

Correctness does matter in things like electronics and computing; I would expect I'd be preaching to the choir to explain this in an electronics forum, but this forum is quickly demonstrating itself to be a very toxic and non-constructive environment. As you've just conceded that I provided information that significantly clarifies a real and fairly widespread problem with these boards, I don't think accusing me of "muddying the waters" makes a lot of sense or is particularly fair.

Some moderator please feel free to close this topic, as I've already found my own answer and helped to document it for other people who are going to encounter the same problem. No interest in further debating with people who are allergic to identifying and acknowledging this as the problem that it is with a certain batch of Nano BLE Rev 2s.

"I SAID GOOD DAY!"

1 Like

Yes, have a nice day. I might read your novel later; I kind of dozed off when we looked off into dictionary area.

1 Like

Topic closed at the request of the OP.