RGB.mirror() at bootloader getting a solid red

Using the below code in DFU mode the mirror function is keeping the red on all the time while it flashes yellow. In running mode the colors are working correctly.

Electron
0.6.1rc1

Thoughts?

#include "application.h"

STARTUP(fastButtonCheck());

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);

#define redRGB B1 
#define greenRGB B2 
#define blueRGB B0 

void setup() {

  // disable on-board RGB LED
  pinMode(RGBR, INPUT_PULLUP);
  pinMode(RGBG, INPUT_PULLUP);
  pinMode(RGBB, INPUT_PULLUP);

  RGB.mirrorTo(redRGB, greenRGB, blueRGB, true, true);
  Serial.begin(9600);
}

void loop() {
 
}

Can you explain in a bit more detail what your are expecting to happen and what is happening in reality?

What do you have connected to B1, B2, and B0?

@harrisonhjones i have the same RGB led connected to the B pins as on the electron. The pin connections are below.

redRGB B1
greenRGB B2
blueRGB B0

what should happen is that when rgb.mirror is enabled in bootloader mode and while in DFU mode the rgb should flash yellow. What is actually happening is that the Red pin is staying active (lit constantly) but the rgb is still flashing a yellow color . It seems like pin B1 is in a different default state from the other B0 and B2 pin while in DFU mode.

Have you tried just independently turning on and off the B0, B1, and B2 pins using DigitalWrite to test that they are working? I’d probably comment out the mirrorTo command

@harrisonhjones, All the RGB are working correctly out of bootloader. Heres a slow mode video showing when the electron wakes up from deep sleep by a button press, in the beginning you see the red flash quickly (at 4 sec in video) before the firmware loads and goes through the setup functions. later the white then get lit

The video is interesting but I’ll admit I don’t quite know what I’m looking at. Can you still try a basic test of looping through B0, B1, and B2 to ensure each output is working as expected?

I verified each led works properly when i used the below to test it. Here’s another video (also in slow motion) showing the device in DFU mode. The red is constantly on.

    RGB.control(true);
    RGB.color(255,0,0);
    delay(500);
    RGB.color(0,255,0);
    delay(500);
    RGB.color(0,0,255);
    delay(500);
    RGB.control(false);

I might have missed the bit in above discussion, but AFAIK in DFU Mode none of your code is run prior entering DFU mode (when initiating it via bootloader).

And to second @harrisonhjones on this

You’ve got the device hidden in an enclosure and we have no idea whether we are looking at the on-board RGB LED or your own or a combination of both through that peep hole.

But the observation that B1 does not stay in Hi-Z when in DFU Mode may be something for @BDub to look into and comment on.

@wesner0019, Thanks for reporting this. This is an oversight in 0.6.1-rc1 with Electron and TIM8 pins in particular (B0 and B1). I have created an issue in github: https://github.com/spark/firmware/issues/1220 and already submitted a PR https://github.com/spark/firmware/pull/1221

@ScruffR RGB.mirrorTo(redRGB, greenRGB, blueRGB, true, true); persists the configuration to the DCT allowing the bootloader to read it and configure Timers and PWM pins accordingly.

2 Likes

@avtolstoy, thanks for the clarification - good to know :+1:

0.6.1-rc.2 is out now. BTW you must include this RGB.mirrorTo() call in STARTUP() if you want to have LED signaling from the time of boot. Even though it’s persistent in the bootloader, it is not persistent in system firmware.

#include "Particle.h"

#define RED_RGB B0
#define GREEB_RGB B1
#define BLUE_RGB B2

// false = common cathode, true = persist in bootloader
STARTUP(RGB.mirrorTo(RED_RGB, GREEN_RGB, BLUE_RGB, false, true);)

void setup() {
  // disable on-board RGB LED, or not if you want to verify external matches internal
  // pinMode(RGBR, INPUT_PULLUP);
  // pinMode(RGBG, INPUT_PULLUP);
  // pinMode(RGBB, INPUT_PULLUP);
}

void loop() {

}
3 Likes