On Sun, Dec 20, 2020 at 01:18:42PM -0300, Alan Carvalho de Assis wrote: > Hi Bernd, > > I develop a product for a customer some years ago using the SAMD21 > with USB CDC/ACM and it worked fine. It was based on NuttX 7.27
Might be a combination with FreeBSD as host. My test host is a RockPro (arm64) running FreeBSD current. It runs a lot of USB devices, but I remember having seen similar problems with a chinese PL2303 cable. Maybe FreeBSD is sensitive to some kind of unexpected behavour. Will try to reproduce the problem with a Linux system. And will try to find out if I can manage to use any of my signal analysers to analyse full speed USB. The clock shouldn't be the cause anymore. > The board was using a 8MHz crystal. DPLL or DFLL? The DFLL code clearly has a problem as my symptoms with the uart had shown, but only happened on some devices. My work arround at that time was to use the DPLL instead. I will submit a pull request for that, including the missing USB sync support. > > BR, > > Alan > > On 12/15/20, Bernd Walter <ti...@cicely7.cicely.de> wrote: > > On Tue, Dec 15, 2020 at 07:28:38PM +0100, Bernd Walter wrote: > >> Ich have some older boards with an at91samd21j18, but without xtal. > >> I use them with USB and like to convert the code wo NuttX. > >> So far I'd used the Atmel-ASF to setup the clock and for USB stack > >> under FreeRTOS. > >> However, after reinspecting I hadn't used the correct clock setup, > >> which would be using the DFLL with USB SOF as reference clock. > >> Instead I used the internal 32kHz RC and rasied it with the DFLL. > >> Nonetheless it worked fine. > >> > >> On another board I already noticed that something is wrong with the > >> DFLL under NuttX. > >> It was a board with XTAL, on which I initially hadn't used the XTAL > >> and instead raised the internal 8MHz with the DFLL. > >> On some boards I couldn't use the UART at 115200 bps because the > >> clock was off. > >> This was unexpected, since the 8MHz is claimed to be precise. > >> However, what was more unexpected that I have had exactly the same > >> offset by using an external 16MHz xtal. > >> In the end I dropped the DFLL and used the DPLL instead, which worked > >> fine. > >> > >> I modified the clock init code to support USB clock recovery and > >> in didn't work at first. > >> After modifying some other things I got my 48MHz, at least USB > >> came up. > >> Now I have another problem. > >> USB isn't stable. > >> I use ACM-TTY and my main routine only loops on printing a counter > >> and short sleep. > >> After 1-2minutes USB dies off. > >> Now I wonder if this is still something clock related or if there > >> is something else wrong with USB on the SAMD21. > >> > >> I will do further tests - I have some boards with a 16MHz xtal and > >> USB connector. > >> I also never checked if the DFLL has locked or not. > >> But at this point I'm also open for other peoples experiences. > > > > A followup on that. > > I'm now running on a similar board, which has a 16MHz xtal. > > GCLK0/USB is running of the DPLL and I still have the problem that USB > > locks up after a while. > > I don't think this is clock related anymore, but I'm also not sure if > > this is even USB as such, although my code is faily simple. > > > > I can do a pull request on my DFLL changes, which I think are the > > correct thing to do. > > There are some errata related bug workarounds and fixes a wrong > > initialisation order. > > And also adds support for USB clock recovery. > > > > -- > > B.Walter <be...@bwct.de> http://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > -- B.Walter <be...@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
