incorrect CircuitPython status colors on PyRuler

[siddacious]

Last night I was testing the keyboard code on the PyRuler and everything was working fine after I updated the code a few times.

This morning I went to try the new code @ladyada wrote and my ruler will not show up as a CIRCUITPY drive, nor does a USB serial port show up.

About 6.5 seconds after plugging in the ruler would result in this mesage in dmesg: 2068082.010921 AppleUSBCDCCompositeDevice@: AppleUSBHostCompositeDevice::ConfigureDevice: unable to set a configuration (0xe0005000)

I've tried different cables, rebooting my laptop, plugging directly into the laptop with a USB-C to Micro-USB cable, going through my thunderbolt hub, all to no avail.

TRINKETBOOT drive shows up without issue

I did breifly have it show up and start typing Ω over and over until I unplugged it. Didn't have the presence of mind to check the circuitpy drive before unplugging it and it hasn't happened since.

[siddacious]

When plugged in, the dotstar is magenta/fuchsia as soon as it is plugged in and stays that way.

Double tapping reset to try to get into the bootloader just now didn't work, the dotstar is solid light blue and there is no TRINKETBOOT. Single reset also resolves to a blue dotstar after the BOOT attempt until the ruler's cable is remove and re-inserted which makes the dotstar pink again.

Just tried again and the BOOT drive works again, maybe user error.

Let me know if there is anything else I should test

[jerryneedell]

I just plugged mine in -- and it went to Magenta. need fairly slow doubletap but got TRINKETBOOT and green Dotstar. Reset went back to magenta - stays magenta even when stopping code.py and going to REPL. Running factory code.

[tannewt]

@siddacious or @jerryneedell can you get a backtrace? Maybe load the pyruler board def on a metro m0 to do it easily.

[jerryneedell]

@tannewt what point are you looking for a backtrace from? What version of code was this?

[tannewt]

I'm curious to know when the status LED is purple where the code is stuck.

[jerryneedell]

ah OK -- I'll try to dig into this over the weekend.

[tannewt]

Thank you!

[jerryneedell]

I have my J-Link connected to the PyRuler:

I looked at the attempts to change the color of the LED during the boot process and it looks like it is trying to set it as expected but the LED is not responding -- it just stays magenta.

(gdb) mon reset
Resetting target
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) traceback
Undefined command: "traceback".  Try "help".
(gdb) backtrace
#0  new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
#1  0x0000c8de in rgb_led_status_init () at ../../supervisor/shared/rgb_led_status.c:145
#2  0x000245ea in main () at ../../main.c:401
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) backtrace
#0  new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
#1  0x00024276 in run_boot_py (safe_mode=safe_mode@entry=NO_SAFE_MODE) at ../../main.c:303
#2  0x00024640 in main () at ../../main.c:427
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) backtrace
#0  new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
#1  0x0000c8de in rgb_led_status_init () at ../../supervisor/shared/rgb_led_status.c:145
#2  0x0000c94a in reset_pin_number (pin_number=pin_number@entry=0 '\000') at common-hal/microcontroller/Pin.c:132
#3  0x0000c97c in reset_status_led () at ../../supervisor/shared/rgb_led_status.c:154
#4  0x0001ac54 in start_mp (heap=0x20000fb4 <allocations>, heap@entry=0x42000001) at ../../main.c:93
#5  0x000242e4 in run_boot_py (safe_mode=safe_mode@entry=NO_SAFE_MODE) at ../../main.c:357
#6  0x00024640 in main () at ../../main.c:427
(gdb) print/x rgb_adjusted
$45 = 0x30
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) backtrace
#0  new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
#1  0x0000c8de in rgb_led_status_init () at ../../supervisor/shared/rgb_led_status.c:145
#2  0x0000c94a in reset_pin_number (pin_number=pin_number@entry=1 '\001') at common-hal/microcontroller/Pin.c:132
#3  0x0000c982 in reset_status_led () at ../../supervisor/shared/rgb_led_status.c:155
#4  0x0001ac54 in start_mp (heap=0x20000fb4 <allocations>, heap@entry=0x42000001) at ../../main.c:93
#5  0x000242e4 in run_boot_py (safe_mode=safe_mode@entry=NO_SAFE_MODE) at ../../main.c:357
#6  0x00024640 in main () at ../../main.c:427
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) print/x rgb_adjusted
$46 = 0x30
(gdb) cont
Continuing.

Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168     current_status_color = rgb;
(gdb) print/x rgb_adjusted
$47 = 0x3000
(gdb) backtrace
#0  new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
#1  0x00024e52 in run_code_py (safe_mode=NO_SAFE_MODE) at ../../main.c:226
#2  main () at ../../main.c:445
(gdb) 

[jerryneedell]

Note: I am running with current master

Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-189-g85d739847 on 2019-08-17; Adafruit PyRuler with samd21e18
>>> 

and I am only looking into the magenta LED issue. I do not have any other problems with the USB enumeration. The board appears to be working normally. The DotStar LED also works if I command it from the REPL.

[jerryneedell]

hmmm - FWIW -- I tried building CP for a trinket_m0 and it works normally -- green Dotstar pulsing on boot. I loaded taht same Trinket_mo image to the PyRuler and it give the steady magenta Dotstar as before...

I then put the PyRuler build on the Trinket M0 and the DotStar LED is pulsing green as normal. Not sure if this is telling us anything but thopught it might be useful information

[jerryneedell]

I'v traced through the execution of the with the J-Link and I just don't see what is going wrong. It appears to be attempting to set the color, but the writes are having no apparent effect. The face that it works on the Trinket_M0 but not on the PyRuler makes me wonder if the problem is related to the extra pin definitions on the PyRuler. Is something causing a conflict with the initialization or execution of the writes to the SPI bus at this stage. It works later in the REPL, but not doing the boot process.

Is this possibly related to #2037

[dhalbert]

Is this strangeness on only MacOS or do you see it on Linux or Windows? Is there an interposed hub or similar thing interposed between the board and the Mac? Have you tried a straight connection?

[jerryneedell]

@dhalbert I assume you are referring to the initial enumeration issue and not the magenta LED. I see taht on a Linux system. Do you see the same behavior? Should that be a separate issue?

[dhalbert]

@jerryneedell I don't have a PyRuler (yet), and my indirect testing with the Trinket M0 hasn't been able to reproduce this. Do you see enumeration issues or just the color issue? If you and @siddacious both see the magenta issue, that's odd, but I'll have to wait and see how to reproduce it.

[jerryneedell]

OK -- I have not been able to reproduce it on a Trinket either -- even with the same build. also trinket build does the same magenta on the PyRuler.

[dhalbert]

Maybe @siddacious can put a Saleae on the DotStar data and clock.

[jerryneedell]

I have a salea but how can I get at those signals?

[dhalbert]

very careful tack soldering, I think, or looking at the board and scraping away solder mask from vias.

[siddacious]

@dhalbert I'll see what I can do once I'm done with this MSA301 driver

[jerryneedell]

I'm so confused -- I have second PyRuler (I order too much stuff) -- it behaves differently. started magenta - then goes white then steady blue while code.py is running and when in REPL (this is with factory code CP 4.1.0rc-1) The other pyruler is just magenta all the time....sigh

[KingerNorth]

I've been playing around with the PyRuler as I received it as part of my order a week ago. Right from the beginning I have seen only the Dotstar as a magenta light. At no time have I seen this change when plugged in or when functioning. I did alter the code as recommended to enable the keyboard by setting it True. What also happens is that I don't get the correct characters for the ohm and pi touch pads, but I do get the mu, µ, character and the DigiKey url. For ohm I get Û, and for pi I get Ò. When I single press the reset the PyRuler reloads and the dotstar remains magenta. When I double press the reset the dotstar goes green and the drive name changes to TRINKETBOOT. I did this on a Windows 10 PC but I get similar results on my MacBook Pro but only the characters for the first 3 touch pads is different. The url works fine. David

[KingerNorth]

I made some changes to the code as suggested by a post from saddacious in the Adafruit forms and now the characters for ohm, mu and pi display properly on my Mac. The characters still do not display properly for Windows 10 PC. Also the dotstar on the PyRuler remains magenta when plugged in to either the Windows 10 PC or my Mac. I also removed a few of the unused files that were originally installed as space is very tight once the code changes were made.

[jerryneedell]

I am now seeing very similar behavior to #2037 on my second PyRuler. with no code.py program, on boot, the dotstar flashes magenta very rapidly. think the blue led is steadily on and the red is flashing so it looks magenta -- once in REPL it remains steady blue. On the first PyRuler discussed above, the LED is steady magenta all the time. Would you prefer to move the DotStart issues to a separate issue -- possibly re-open #2037 with a new name?

[dhalbert]

I tried three PyRulers on Linux. They all enumerate and have normal colors for TRINKETBOOT but not for CircuitPython. The default PyRuler bootloader is 2.0.0-adafruit.7. I tried that bootloader on a regular Trinket: the DotStar is fine with CircuitPython, and I also tried the 3.7.0 bootloader on the PyRuler, with no improvement. So it's not the bootloader.

[dhalbert]

More testing: I am not having trouble with enumeration with PyRulers on MacOS Mojave 10.14.6.

I added

CIRCUITPY_BITBANG_APA102 = 1

to boards/pyruler/mpconfigboard.mk and rebuilt, and now I appear to get correct colors for CircuitPython (given my limited color vision). The pulsing DotStar when the REPL is running is rather rough-looking: I don't see the same issue on a regular Trinket when setting CIRCUITPY_BITBANG_APA102 = 1. This may have to do with the particular batch of DotStars used for the rulers, but it needs further investigation.

I directed the 48MHz DFLL clock to a pin temporarily and it is indeed running at 48Mhz, according to my 'scope.

The NVM User Row fuse values were somewhat different between a Trinket M0 I had on hand and all the PyRulers. The values are below. I reset the fuses on one PyRuler to match the Trinket M0, and it didn't make any difference.

Pin designations A4 and A2 were swapped between Trinket M0 and PyRuler, but all other pins are the same.

[dhalbert]

Further testing:

I changed the pins used for MICROPY_HW_APA_MOSI and _SCK to be the pins assigned for board.MOSI, and board.SCK, and took those pins out of general use. I attached an external DotStar strip so its first DotStar would take the place of the onboard one. It appeared to work fine, and pulsed green smoothly.

I went back to the onboard DotStar and tried changing the SPI clock rate up and down by one and two orders of magnitude, and tried other combinations of polarity and phase just for fun. Somewhat different things happened, but there was no improvement. I compared the Trinket and PyRUler board designs more carefully and don't see any issue. Perhaps there is noise on the APA102 lines??

I tried adding the outboard DotStar strip in parallel with the onboard DS, but it's extremely hard to probe the onboard DS terminals. Next step is perhaps to tack some very thin wires to the DS terminals or the SAMD chip terminals, but it requires some very fine soldering. I could then look at the signals, try the parallel thing again, etc.

[dhalbert]

I forced the MOSI and SCK lines to high drive mode, and I get the stuttering green pulsing. This makes sense, because bitbangio uses DigitalInOut, which forces high drive.

Most interestingly, if I probe the clock line with a jumper or other lead, but unconnected, then the pulsing also settles down to a somewhat weak pulsing. I think the added capacitance is reducing some noise or ringing. Doing the same on a regular Trinket M0 has no effect.

This makes me pretty suspicious that this is an electrical problem. Will consult with the hw folks.

[ladyada]

can you try it in arduino?

[dhalbert]

Turns out not a board hardware problem, but new DotStars were not tolerant of off-spec writes.

@siddacious If you still have enumeration issues on MacOS, could you open another issue? Thanks. Dropping that from this issue.

[dhalbert]

Fixed by #2102.