Comments (11)
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
from uf2-samdx1.
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.
from uf2-samdx1.
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.
from uf2-samdx1.
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!
from uf2-samdx1.
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?
from uf2-samdx1.
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.
from uf2-samdx1.
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.
from uf2-samdx1.
(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.
from uf2-samdx1.
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.
from uf2-samdx1.
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)
from uf2-samdx1.
Should be fixed by #117. Please reopen if not true.
from uf2-samdx1.
Related Issues (20)
- SAMD21 Clock Config HOT 5
- NeoKey Trinkey update files missing HOT 3
- SAME51 update for Adafruit Feather M4 CAN? HOT 2
- Compiling for the SAMDA1G16B HOT 5
- reset into bootloader from user code? HOT 4
- circuit playground express 3.14 macos Monterey HOT 4
- Having an issue with USB device disappearing if the programmer is not connected HOT 1
- Makefile issues HOT 4
- macOS 13.0 (Ventura) Finder gives error when uploading UF2 files HOT 4
- Linking issue HOT 1
- Custom pin mapping for ATSAMD21G18A HOT 1
- Problem building the project in VS code HOT 1
- Reading logs - how???? HOT 3
- MKR Vidor 4000 Arduino Sketch Upload halts at around 50% only when loaded via uf2 bootloader
- Building an "unlocked" (no flash write protection) bootloader? HOT 1
- Change the filesystem be changed to FAT or FAT32 ? HOT 1
- Double definition of WDT for SAMD51
- Adding a timeout to the bootloader HOT 12
- Add Wire Mux HOT 1
- Flash corruptioin on SAMD51 HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uf2-samdx1.