AVR Freaks

thanks Steve, that makes sense. However, I don't have any reason to believe that something is wrong with my code or clock configuration. The boards all work fine, there is no problem with USB communication, at least not that I know of. Out of the last 30 or so boards I made only two are showing the behavoir described above. What puzzles me is that these boards exhibit no quirks when the DFLL USBSOF calibration is disabled - while all other boards behave exactly the other way around (as you would expect).

Why do you think deep sleep will be enabled when the USB interface is enabled? The only thing that could send the CPU to sleep is a suspend signal from the host but that is not the case as far as I can see - unless Windows issues a suspend signal immediately after enumeration without a resume.

Something must be causing a deviation or otherwise DFLL calibration would work as it's supposed to.

I need to figure out how to measure actual CPU clock when DFLL USBSOF calibration is enabled first and then report back to be sure we're not wasting time groping in the dark or looking in the wrong place.

OK, so I've got another piece of silicon that needs additional tuning. This time I figured out how to correctly output CPU clock on a GPIO pin. Jfyi, with the standard DFLL COMP setting of 0xBB80 I occasionally get what I presume is some kind of synchronization error when the USB host initiates communication (in this case a SET_REPORT request to update the status of the lock lights). I have a scope but I don't have a hardware USB protocol analyzer to see what's going on on the bus.

Here are my findings, quite puzzling still and disappointing, because I haven't gained any new insight:

Setup 1:

Default COMP value for DFLL source USB SOF: 0xBB80, i.e. 48000. Main system clock SYSCLK is tuned to 48MHz, CPU clock is SYSCLK/4, i.e. scaled down to 12 MHz. Clock output read with oscilloscope is 12.0000 MHz +/-0.0160. I conclude that the DFLL works nicely, clock speeds seem to be quite accurate - but, oh my!, the supposed occasional sync errors occur notwithstanding!

Setup 2:

Tuned COMP value for DFLL source USB SOF: 0xBD00, i.e. 48384. Main system clock SYSCLK is tuned to 48.384MHz, CPU clock is SYSCLK/4, i.e. scaled down to 12.096 MHz. Clock output read with oscilloscope is now 12.0960 MHz +/-0.0160. I conclude that the DFLL still works nicely, but the clock speeds are now actually significantly off - but, oh my!, the supposed occasional sync errors are gone and everyhing works consistently fine!

I said 'supposed sync errors'. Since tuning the DFLL COMP value, more precisely: since increasing the COMP value, seems to fix the issue for a particular piece of silicon, I conclude two things:

1. the clocks of the USB host and my XMEGA client device must be somehow out of sync without tuning. Otherwise I cannot understand why the client would occasionally 'miss' incoming requests (or receive corrupt data or whatnot, I don't know yet what is going on exactly)

2. The XMEGAs USB clock must have been running too slow - even though the measured CPU clock speed seems to suggest that the USB clock has increased as expected.

What's going on? Does my reasoning even make sense? What else could be causing the described behavior if not the XMEGA itself?

thanks for your reply, Steve, I appreciate it. Too bad you're the only one chiming in! :(

Yes, I know.

However, the device didn't got to sleep at any point. The first method I tried to export the PER clock was toggling an arbitrary pin as fast as possible. For some reason that didn't work. It probably had something to do with other parts of the code (it's a full blown keyboard firmware). Commenting out a couple of sections apparently was not enough. There's also a chance I had just missed something simple, s.a. an if() or I put my pin toggle code inside the wrong while() loop, because I was in a hurry. So, when I tried another method using 'PORTCFG.CLKEVOUT = PORTCFG_CLKOUT_PC7_gc' to export the PER clock to Pin 7 on Port C, it worked right away.

No. It doesn't have anything to do with the cable or USB connector. Like I said, the XMEGAs are mounted on decent PCBs based on a decent layout and made by a professional fab house. I'm pretty sure I've routed the USB signal lines correctly (as close as possible together, parallel, no vias, the least amount of angles possible). The traces are only about 6 cm in length, I don't see a problem there. I have had absolutely no problems with these PCBs. HOWEVER, I cannot be sure I did a good job unless I run a hardware check on the boards - but I don't have the equipment to do that. The fact of the matter is: 9 out of 10 boards, heck, 90 out of 100 boards, do not exhibit the behavior described. Also - I cannot change anything about the PCB. Changing the COMP settings in the firmware for the XMEGA will fix the issue, so naturally I'm going to inquire into that rather than the PCB.