Question on USBCore.cpp -- maybe bug -- maybe just me

I am building a system with ATMEGA32U4 clocked at 16MHz on 3.3V. Atmel says I should run F_CPU at 8MHz (prescale system clock by 2) due to the low VCC. Yes, I know it will probably work at 16MHz but this may turn into a commercial product and I don't want to push my luck.

I've got the bootloader (Caterina LilyPadUSB) tweaked and working. It sets system clock prescale to divide by two. In the Makefile, I have F_USB=16MHz and F_CPU=8MHz.

The problem is with the Arduino builds. They don't setup the PLLCSR register correctly and the device fails to enumerate on USB.

I traced this to the file USBCore.cpp and the method USBDevice_::attach(). It uses F_CPU to figure out how to set the bits in PLLCSR. I think it should be using F_USB instead because the PLL is fed directly by the input clock -- not by the prescaled system clock. I have changed the code in the attach() method to look at F_USB instead of F_CPU and it all works fine now.

In summary, I think I've solved the problem for myself but I'm wondering if there is a bug there in USBCore.cpp -- should it be setting bits in PLLCSR based on F_CPU or F_USB?

I just wanted to give you this note in case it might be helpful.

Cheers,

USBCore.cpp : https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/USBCore.cpp

Why tweak ? Why don't you use a crystal of 8MHz ?

The LilyPad USB is already a ATmega32U4 at 8MHz. You can use that bootloader as it is. If you want an external crystal, set the fuses for an external crystal and use a crystal of 8MHz.

When the bootloader is okay and you compile for the LilyPad USB, everything will be compiled for 8MHz.
If you want to, you could also make your own definition for board.txt.

I can find the "F_USB" only in the makefile for the bootloader of the Caterina Lilypad USB. It is used when the prescaler is used. So you might be right. Perhaps you are the only one that uses a 16MHz crystal for a 8MHz Arduino, and no one has bumped into that bug yet.

I'm still not sure if it is okay to use a 16MHz crystal at 3.3V. The prescaler might fix the cpu part, but the usb part may still have troubles.

I'm still not sure if it is okay to use a 16MHz crystal at 3.3V. The prescaler might fix the cpu part, but the usb part may still have troubles.

The oscillator may have problems. The people who overclock AVRs (20Hz attiny at 36MHz to do VGA graphics) use an external oscillator (not external crystal - an actual external oscillator.) Because the oscillator is the first thing to stop working. (whether it's the first thing to stop working as you reduce voltage is a separate question...)

This project needs a particularly accurate/stable clock so I'm using a TCXO. I would have prefered to use an 8MHz TCXO but it seems that those are not available off-the-shelf so I had to settle for 16MHz. If necessary I can see about getting one at 8MHz but Digikey/Mouser don't seem to stock them.

I know of no Arduino variants as of now that do system clock prescaling so I think you're right that it is just me seeing this as of now.

And thanks for pointing out the 16MHz issue at 3.3V. I don't know where I got the idea that it was okay to have an external clock applied at 16MHz with prescaling enabled. Maybe it's not okay. I will look into that some more. A more careful reading of the 32U4 data sheet makes it sound like it is NOT okay.

Both Mouser and Digikey have two Fox FXTC-HE73 8MHz 3.3V TCXOs, but they are not available/obsolete and without a price tag. Farnell/element-14 has none. That is very weird.

Could this be a XY-problem ? http://xyproblem.info/
Can you tell why you need such an accurate clock ?