Circuit Playground Express - Unexpected Button B Behavior After External LED

[epeach]

Moving this from an email thread, as requested.

A few reports came in to Code.org about our AppLab and Circuit Playground integration. Users are seeing unexpected behavior with Button B on the Circuit Playground Express in our Maker App integration when running a project that connects to an external LED. I followed up and was able to confirm that this is limited to that button and is not reproducible on the Circuit Playground Classic.

Here is a project that can be used to reproduce the issue: https://studio.code.org/projects/applab/91tPzAeXGuSthP8hNB1dmPznJOwfyTfU9LzhbWv2YXY.

Gif show what happens when I run the program with the Circuit Playground Express connection. In the gif, after selecting "Run", the "Up" condition is triggered before I push a button. When I press the B Button, the "Down" condition is triggered, but the "Up" condition is not. When I press the button again, nothing happens. However, when I touch the silver metal part of Button B with my fingertip or conductive material without compressing the button, the "Down" and "Up" events are triggered, behaving similarly to a capacitive touch sensor.

Please let me know if I can provide any additional information.

cc: @kyliemoden

[ladyada]

hihi apologies i was prepping to reply to your email today :) is there a debug output from javascript that says what bytes are being sent over Serial (or webusb) ? that way i can replicate quickly!

[epeach]

Hi there! I've copied below and attached a .txt file with the log output from when I run this project: https://studio.code.org/projects/applab/91tPzAeXGuSthP8hNB1dmPznJOwfyTfU9LzhbWv2YXY. The text log includes the console.logs that are triggered in that project (when the board is connected, and when the "Up" and "Down" are detected in the project), so that we can see how it's interacting with the log. When testing this project, I clicked "Run", then clicked the B Button thrice, the touched the silver metal part of Button B with my fingertip, without pressing the button down. Please let me know if you need any more info or logs!

["f9"]  ["f0", "79", "f7"]  ["f0", "6b", "f7"]  ["f0", "69", "f7"]  ["f0", "7a", "64", "0", "f7"]  ["f4", "4", "2"]  ["c4", "1"]  ["f4", "5", "2"]  ["c5", "1"]  ["f4", "0", "2"]  ["c0", "1"]  ["f0", "40", "10", "0", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "1", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "2", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "3", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "4", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "5", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "6", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "7", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "8", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f0", "40", "10", "9", "0", "0", "0", "0", "f7"]  ["f0", "40", "11", "f7"]  ["f4", "d", "3"]  ["f4", "15", "0"]  ["92", "20", "0"]  ["d2", "1"]  ["f4", "4", "0"]  ["d0", "1"]  ["f4", "13", "0"]  ["d2", "1"] {output: "Connected", fromConsoleLog: true}  ["f4", "2", "1"]  ["90", "4", "0"] {output: "Down", fromConsoleLog: true} {output: "Up", fromConsoleLog: true}  ["90", "4", "0"] {output: "Down", fromConsoleLog: true} {output: "Up", fromConsoleLog: true} {output: "Up", fromConsoleLog: true} {output: "Up", fromConsoleLog: true} {output: "Up", fromConsoleLog: true}  ["90", "4", "0"] {output: "Down", fromConsoleLog: true}  ["90", "4", "0"] {output: "Down", fromConsoleLog: true} {output: "Up", fromConsoleLog: true}  ["90", "4", "0"] {output: "Down", fromConsoleLog: true}

CPE_ButtonB_Serial.txt

[KylieModen]

@ladyada is there any other information needed to help investigate this issue? We would love to provide an update to the teacher who originally reported this issue to us - is there any fix ETA we can share?

[ladyada]

hihi pardon the delay, was a little under the weather - i am investigating... firmata is very 'fun' to debug :D

[ladyada]

ok i have this set up now...i wanted to make sure i had plenty of time to understand whats up

[ladyada]

this is so weird @KylieModen can you reproduce this because i cant? i m sure there's something going on...we just have to figure out what. can you send me your UF2? double click reset, remove CURRENT.UF2 and maybe zip the file then drag it here

[KylieModen]

@epeach Erin, can you try to repro again and provide the requested info above?

[ladyada]

thank you - sorry again for the delay!

[epeach]

Hi there! I'm still able to reproduce this using the project code shown above. I've attached a zip of the CURRENT.UF2. Please let me know if there is more additional information needed. CURRENT.zip

[ladyada]

@epeach ok just to verify, can you try this?

if you run that, does the right button work as you expect, with the led turning on when pressed and the correct console out

[ladyada]

does createLed(n) make a neopixel or is it a digital on/off?

[epeach]

Hi there! I tested the code in the screenshot above and it works as expected. To the best of our knowledge, the unexpected behavior is limited to code that references LEDs external to the board.

createLed(n) does not make a NeoPixel, just a digital on/off. We expect the LED object it creates to be able to handle the same commands that the LED on the board accepts (on, off, blink, toggle, and pulse). This is our documentation for the createLed() function: https://studio.code.org/docs/applab/createled/

[ladyada]

ok i just tried this code

if (boardConnected()) {
  console.log("Connected");
  var myLed = createLed(13);
}

onBoardEvent(buttonR, "up", function(event) {
  console.log("Up");
  myLed.off();
});

onBoardEvent(buttonR, "down", function(event) {
  console.log("Down");
  myLed.on();
});

and it also seems to work, can you try it? its a little different

[epeach]

When I use that code, it works as expected and I do not reproduce the original error.

[ladyada]

kk - does it stop working if you move the var myLed outside of boardConnected() or if you delete one or the other of the myLed function calls?

[epeach]

I tried a variety of edits to see what would cause it to break. With the code listed above, moving the myLed outside of the boardConnected and deleting one of the myLed function calls, didn't seem to break the code. However, when I changed the pin number from 13 to either 2 or 0, I did reproduce the error.

[ladyada]

what pad are you expecting to be connected to 'pin 2'?

[epeach]

Hi! I think that is the root of the issue. For 'Pin2', when using the Express Board, I would expect the 'A5' pad to be connected. In the Code.org code, we do some mapping to translate between the Classic and Express boards. I was playing around in our code and noticed that if I removed our pin mapping between the Classic and Express, and ran createLed('A5'), the unexpected behavior where the Button B doesn't run the right console.logs resolves and the behavior is as expected. However, the external connected LED does not light up, as expected from the code. I've dove into the code more and tracked things through from createLed to how we turn it on and off. A lot of that goes through https://github.com/rwaldron/playground-io so I'm trying to figure out how that code interacts with the different pins from both the Classic and Express, but am currently a bit stuck there.

Would you recommend a specific protocol for managing the two sets of pin names between the Classic and Express?

[ladyada]

ok here's the variant mapping for the circuitplayground express https://github.com/adafruit/ArduinoCore-samd/blob/master/variants/circuitplay/variant.cpp digital 2 (the third entry) maps to SDA pad which on the classic is the same - D2 and SDA are the same https://learn.adafruit.com/introducing-circuit-playground/guided-tour

the firmata code we wrote does some shim remapping so that the original code.org code pins get re-mapped to the new ones https://github.com/adafruit/CircuitPlaygroundFirmata/blob/master/CircuitPlaygroundFirmata_Express_CodeOrg/CircuitPlaygroundFirmata_Express_CodeOrg.ino#L9 so code.org should not have to do digital remapping on its own (that was the goal in this custom firmata build). in particular, digital 2 / SDA shouldn't be remapped because they're the same pin names on both boards. so if theres some code.org code that tries to do some funky remapping for digital 2, i think it probably should not be!

[ladyada]

@epeach hihi checkin' in - were y'all able to try removing 'remapping' for D2 in codeorg?

[KylieModen]

Hi there, a quick update that we plan to look at the remapping when Erin is back from vacation and has time to review, likely a few weeks. Appreciate your patience until we can take a look at that proposed solution.

[ladyada]

all good - enjoy the vaca!!!

[breville]

A quick update:

So far, I have a repro and I'm basically at the same place that @epeach was last year: we have a small program that accepts presses of the left & right buttons, and also attempts to blink an external LED connected via alligator clips to GND & A5.

We have some simple pin remappings in our code here. What I've observed is that bypassing those remappings fixes the problem in which the Right button events stop working. However, the remappings are required for the LED to turn on. Specifically, by the time we get to our fork of johnny-five's lib/led.js, say here, the LED only turns on if we are passing through pin value 2, but doesn't work if we pass pin value A5.

Any thoughts? We are happy to pair up in any form that would be helpful.