Trouble with a NeoPixel on a Trinket M0 clone about uf2-samdx1

[alexwhittemore]

A LITTLE more info: that goofy case for line 138 (last code block above) causes the bootloader to take ~23s to hit user code if #define CRYSTALLESS 1, and about ~27s if #define CRYSTALLESS 0

[dhalbert]

The bootloader is now always crystalless: see inc/uf2.h, which sets it to 1 if it's not defined. Also, src/init_samd21.c does an #if defined(CRYSTALLESS) check. So the value doesn't actually matter. Setting it to zero will not turn off CRYSTALLESS. That's kind of a bug: that #if check should be #if CRYSTALLESS.

It does sound like your clocks are messed up in some way, running very slowly. That would explain the NeoPixel color oddities.

[dhalbert]

Note the commented-out lines here: https://github.com/adafruit/uf2-samdx1/blob/master/src/init_samd21.c#L124, which will output GCLK0 to pin PA30 for debugging: you can check the clock speed with a logic analyzer or scope. And you don't have to use PA30: GLCK_IO[0] is available on other pins as well for the SAMD21E, as listed in Table 7-1 in the SAMx21 datasheet.

[alexwhittemore]

Great info, thanks! I'll try that to see if it reveals any particularly interesting info. But assuming the clock IS messed up, why would it be messed up at that point and not during the entire bootloader operation?

You're super helpful, by the way, thanks!

[alexwhittemore]

Hmmm... With those two lines uncommented, I get 0V DC out of SWCLK. After a manual reset with the debugger disconnected, so no funny business with the pin muxes being configured for SWD still, either. Is it possible for the clock to be that badly misconfigured, and the core is falling back to a different clock?

[alexwhittemore]

Oh. How about this. The bootloader clock works just fine and dandy, IFF the SAMD is connected to a USB host. I just looked through init_samd21.c and saw some notes about "USB correction" and thought to try that.

As it happens, I'm trying to bootload primarily via UART, ultimately. Thoughts on how to get the clock working right, WITHOUT the guarantee of USB sync?

Edit: Huh... still no clock out of SWCLK with those lines uncommented, even plugged into USB and working with good timing.

Edit 2: Also, I spent the last half an hour smashing my forehead into a wall trying to figure out why my JLink connected to a Win10 Parallels VM would NOT upload the bootloader code with Atmel Studio, when it's been working all day.

Turns out, it only works when the laptop is plugged in. Like, plugged in to power. No power = jlink-in-guest doesn't work.

Embedded systems are weird.

[alexwhittemore]

Bit of a status update: Originally, my issue was that the neopixel would get stuck on full-white until functional application code did something with it. My solution to this point has been "comment out the neopixel" in the bootloader, so it simply doesn't get used.

My problem now is that the same clock problem is fouling up UART loading, which I also need.

The clocking problem isn't present when connected to native USB, as mentioned above, because the USB hardware conditions the main clock PLL with its 1ms sync pulse - otherwise, even with a good system clock, usb would work poorly. This isn't doing me much good, since bootloading over UART of course implies I don't want any USB connected.

Simply uncommenting the two lines @dhalbert mentioned didn't do the trick, because as line 117 above them states,

// Add GCLK_GENCTRL_OE below to output GCLK0 on the SWCLK pin.

In other words, line 117+:
// Add GCLK_GENCTRL_OE below to output GCLK0 on the SWCLK pin.

GCLK->GENCTRL.reg =
        GCLK_GENCTRL_ID(0) | GCLK_GENCTRL_SRC_DFLL48M | GCLK_GENCTRL_IDC | GCLK_GENCTRL_GENEN;
gclk_sync();

should become

GCLK->GENCTRL.reg =
        GCLK_GENCTRL_ID(0) | GCLK_GENCTRL_SRC_DFLL48M | GCLK_GENCTRL_IDC | GCLK_GENCTRL_GENEN | GCLK_GENCTRL_OE;
gclk_sync();

and THEN the clock output will work with the other lines (125+127) uncommented.

Ok, cool. I took that a step further and added that code to a generic led blink sketch, where it also works. So now I've got clock output both in (broken) bootloader and (functional) sketch.

What I've found with this new output is that, with USB plugged in, GCLK0 is quite precisely 48MHz in BOTH situations, and more like 47.15MHz with USB unplugged. And with USB unplugged, I can raise and lower that 47.15MHz by about .05MHz by breathing softly or blowing hard on the uC, so that's neat.

In other words, the 48MHz system clock works just fine and dandy, whether plugged in via USB or not, and in-sketch or not. So something else odd is going on.

I also noticed that the LED_BUILTIN breathing is much slower and smoother when plugged into USB, and kind of frantic (maybe 3Hz?) when not. That animation in the bootloader is driven by

void SysTick_Handler(void) { LED_TICK(); }

so something is going wrong with whatever drives that interrupt. That's about where I'm at.

[alexwhittemore]

(Sorry, this is as much for my own notes now as anything, but I'm sure someone at some point will find it interesting).

I just did another little experiment on my crystal-enabled board. I overrode the crystalless override on uf2.h:22 to allow crystal or not.

Crystal enabled: ~47.97MHz, USB or not.
Crystal disabled: ~46MHz no USB, changing to 48.000MHz when USB plugged in.

Which strikes me as odd, because init_samd21.c:104 SYSCTRL->DFLLCTRL.reg |= SYSCTRL_DFLLCTRL_ENABLE; seems to me like it should enable USB syncing even if the crystal is used. EDIT: Oh, it's because SYSCTRL_DFLLCTRL_USBCRM is included in SYSCTRL->DFLLCTRL.reg = in the crystalless case, but not in the no-crystal case.

But in any event, regardless of the accuracy of the 48MHz clock, the systick handler seems to fire with the wrong frequency in any case.

[alexwhittemore]

I added some lines at the beginning of of led_tick() which is the systick handler in the bootloader:

void led_tick() {
    LED_MSC_ON();
    LED_MSC_OFF();

so now I get a little runt pulse every time systick fires. It's showing me that, regardless of how fast the LED is breathing (slow when USB connected, frantic when independent), the systick handler is firing at 48kHz, best my cursor can tell. Which, of course, jives perfectly with SysTick_Config(1000); (48MHz/1000 = 48kHz).

So now I'm just more confused than when I began.

EDIT: Of course, now that I dig in to how the LED animation code works - if USB isn't enumerated yet, the LED breathes 10x fast, if it IS enumerated, it breathes at 1x.

So USB clock conditioning is, in this case, a total red herring, and serial+LED functionality aren't necessarily related.

[nekuneko]

I have the same Neopixel stuck issue in high white bright on a SAMD21E18A custom board on PA18 pin. But I think it may be caused beacuse of a bootloader compilation issue, because I uploaded the latest bootloader bootloader-feather_m0_express-v3.9.0.bin released here to my official Adafruit Feather M0 Express and get the same problem on with the builtin neopixel brighting in high yellow. Nevertheless flashing the bootloader-feather_m0-v2.0.0-adafruit.5.elf bootloader, this issue doesn't happens.

My solution was to develop a patch for the ArduinoCore-samd in order to keep power off Neopixels at Arduino skechtes code startup. Repo adafruit/ArduinoCore-samd pull-request (ADDED BASIC NEOPIXEL SUPPORT #223)

[dhalbert]

Should be fixed by #117. Please reopen if not true.