search

mattairtech / SAMD-MSD-Bootloader

USB MSD (Mass Storage Device) bootloader for Atmel SAMD chips
Other
36 stars 10 forks source link

DFLL reference clock setting #5

Open awatterott opened 7 years ago

awatterott commented 7 years ago

I saw that the DFLL reference clock is set to 8MHz, but the maximum is 33kHz and so the DFLL will not work in closed loop mode (it will not lock). Datasheet -> Maximum Peripheral Clock Frequencies -> GCLK_DFLL48M_REF

mattairtech commented 7 years ago

Yes, that looks like it might be a problem. The multiplier should be 0xBB80 (the SOF signal is every millisecond). I looked at the ASF files that this came from, and they have (48000000 / 32768), which is also incorrect. I will need to look into the ASF files to see if this value is ignored when using USB calibration. Note that the reference clock will be ignored when the SYSCTRL_DFLLCTRL_USBCRM bit is set. I may add a test to the lock flags, to make sure a lock is happening before continuing (ASF should be doing this).

awatterott commented 7 years ago

When the USB calibration (SOF reference) is activated then the multiplier and reference clock is ignored.

mattairtech commented 7 years ago

The reference clock is ignored, but I did get a failure to enumerate USB by using a much smaller value for the multiplier, but this was with different code that does not use ASF (I plugged the value in to the register directly). I tried exactly half the value, and another smaller value that 0xBB80 was not divisible by. So it seems that this value is important at the register level. I searched for 0xBB80 in ASF and looked at some of the relevant source files to see if they were overriding the value in clocks.conf, but it looks like they are using clocks.conf value directly.

Because the reference clock is ignored, setting it to something below 33KHz should not make any difference, since the reference is actually the 1KHz SOF signal. How do you know you are not getting a lock? In my own experience, these flags simply do not set when in USB clock recovery mode. I checked ASF, and they also explicitly avoid testing these flags with USBCRM. There is an errata about this issue, but it implies that it only happens after a USB suspend. However, they recommend not to ever test the flags with USBCRM. The flags work fine when in closed loop mode without USBCRM, but this bootloader does not use that mode. If the SOF signal is not present, the DFLL will fall back to open-loop mode.

Does the bootloader run at all for you? Does it have USB connection problems?

awatterott commented 7 years ago

No, I have no problems. I just saw the wrong configuration and it will not work, when the USB calibration is deactivated (SYSTEM_CLOCK_DFLL_LOOP_MODE_CLOSED defined). Then the DFLL will not lock and the clock will be not accurate enough for USB. Your current configuration with USB calibration works. Sorry, for the confusion.

mattairtech commented 7 years ago

Oh, I see. I will make those changes so that closed loop mode will work (if an external crystal is installed). Better yet, I would like to use ASF only for the USB stack, so I might change the clock code completely. I support different clock configurations with my port of the Arduino core, so I might do something similar. This code needs updating for the L21 chip as well, but this is a much lower priority right now. I'll keep this issue open until I get it done.

awatterott commented 7 years ago

The default setting in the ASF examples is an external 32kHz crystal and I think most designs also use this. But with the internal oscillator it will work with every design. I have made some USB tests with the internal 8MHz RC oscillator as DFLL reference (without USB calibration) and I found no problems. As prescaler I used 250 to get 32kHz, here are my settings.

mattairtech commented 7 years ago

I have also noticed that USB always works for me when I use the DFLL in open-loop mode, despite the fact that this (and all of the RC oscillators) are not accurate enough across temperature and voltage to meet the USB spec. I imagine it would fail if temperature conditions were sufficiently far from room temperature, or maybe if connected to a host that is less forgiving of out of spec devices (ie: possibly some Apple products). Why not use USB calibration? The 8MHz RC does appear to have better accuracy across temperature than the DFLL in open-loop mode, but with USB calibration, the DFLL is very accurate.

awatterott commented 7 years ago

In open-loop mode (without USB calibration) it is not working on my development notebook (Lenovo + Win7). Since the bootloader needs an USB connection, I would also recommend the USB calibration. I opened the issue, because there are wrong values for the DFLL reference clock when not using the USB calibration and I got it not working in open-loop mode.