ATmega32U4: USB problem when using internal RC clock

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone have any experience using USB on the ATmega32U4 configured with the internal 8MHz oscillator clock source?

I am unable to communicate with the ATmega8 via USB.  |O

My computer (Mac with OS X) does indicate that my board is connected.
I am using an Arduino Uno as a programmer via the ISP interface.
I can successfully burn a boot loader into the chip whilst setting the fuses as required.
My board seems to operate ok and simple test code can be uploaded to it (via the Arduino ISP) and it works as expected.
If the chip is programmed with the fuses set to output the clock on Port C pin 7, then a waveform extremely close to 8MHz is seen.
I have tried setting the LSM bit in UDCON to force low speed USB and this is reported as 1.5MHz by the Computer.
If I try and upload code via the USB connection then the programming fails saying it can't find the device on the port.

Do I have to use a special/modified boot loader to use the internal RC?
Is there anything specific that I have to do in order to get the USB working?
Is there something really basic that I have missed?
Any other suggestions most welcome.
Many thanks in advance...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not a user of this chip.  Like Will Rogers, all I know is what I read in the papers.  The datasheet, in this case.

 

The USB chapter starts out saying that a 48MHz clock is needed. "Figure 21-1. USB controller Block Diagram overview" indicates IntRC as
a possible input into the PLL.

 

So, have you set up the PLL for x6?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought the AVR-USB (not Xmega-USB) would *ONLY* work with either an 8MHz or 16MHz crystal. I'd have to dig a d/s out but I'm pretty sure it tells you that if you are using USB you must use one of these two. I don't believe intRC is ever an option on that chip (for USB work that is).

 

EDIT: Ok, well wrong then - just read 32U4 d/s and it confirms it is possible. I was thinking of 82/162.

Last Edited: Tue. Nov 4, 2014 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't believe intRC is ever an option on that chip (for USB work that is).

 If not (and my recollection is the same as yours) then why is it in the block diagram?

 

 The PLL clock input can be configured to use external low-power crystal
oscillator, external source clock or internal RC (see Section “Crystal-less operation”, page 256).

 

"> 21.4 Crystal-less operation
To reduce external components count and BOM cost, the USB module can be configured to
operate in low-speed mode with internal RC oscillator as input source clock for the PLL. The
internal RC oscillator is factory calibrated to satisfy the USB low speed frequency accuracy
within the 0°C and -40°C temperature range.
For USB full-speed operation only external crystal oscillator or external source clock can be
used.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your reply...  As far as I can see, referring to section 6.10 of the data sheet, the default output from the PLL is 48MHz when the 8MHz RC is enabled.

Last Edited: Tue. Nov 4, 2014 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From data sheet....  I'm 100% you can...

 

21.4  Crystal-less operation

  1. To reduce external components count and BOM cost, the USB module can be configured to operate in low-speed mode with internal RC oscillator as input source clock for the PLL. The internal RC oscillator is factory calibrated to satisfy the USB low speed frequency accuracy within the 0°C and +40°C temperature range.

    For USB full-speed operation only external crystal oscillator or external source clock can be used. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I can see, referring to section 6.10 of the data sheet, the default output from the PLL is 48MHz when the 8MHz RC is enabled....

...if PINDIV is 0, right?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

As far as I can see, referring to section 6.10 of the data sheet, the default output from the PLL is 48MHz when the 8MHz RC is enabled....

...if PINDIV is 0, right?

I have the default value for PINDIV3:0 as 0100 for 48MHz as per the table at end of section 6.10.3

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not PDIV -- PINDIV.

 

Anyway, not my area of expertise.  Does LUFA have any insight into that?
 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Not PDIV -- PINDIV.

 

Anyway, not my area of expertise.  Does LUFA have any insight into that?
 

 

Sorry,  Yes PDIV = 0.  Will look into LUFA.... 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

paulburger wrote:

Does anyone have any experience using USB on the ATmega32U4 configured with the internal 8MHz oscillator clock source?

 

I can successfully burn a boot loader into the chip whilst setting the fuses as required.

I have tried setting the LSM bit in UDCON to force low speed USB and this is reported as 1.5MHz by the Computer.

If I try and upload code via the USB connection then the programming fails saying it can't find the device on the port.

 

theusch wrote:

> 21.4 Crystal-less operation

To reduce external components count and BOM cost, the USB module can be configured to
operate in low-speed mode with internal RC oscillator as input source clock for the PLL. The
internal RC oscillator is factory calibrated to satisfy the USB low speed frequency accuracy
within the 0°C and -40°C temperature range.
For USB full-speed operation only external crystal oscillator or external source clock can be
used.

 

 

The boot loader is most likely using USB full speed mode, which requires a crystal.

 

If it's not too difficult, just connect an 8MHz or 16MHz xtal (with caps) and change the fuses to use the external xtal.

Select 8MHz or 16MHz xtal based on what the boot loader is expecting.

See if it works with the external xtal.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After my post above I read the data and realised that 32U4 is different to 82/162 that I know about (they do need 8/16MHz crystal) so I edited the post but for the umpteenth time this bloody web site did not store the edit that I posted - sorry for the noise!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:

 

 

The boot loader is most likely using USB full speed mode, which requires a crystal.

 

If it's not too difficult, just connect an 8MHz or 16MHz xtal (with caps) and change the fuses to use the external xtal.

Select 8MHz or 16MHz xtal based on what the boot loader is expecting.

See if it works with the external xtal.

 

 

 

 

Thanks for your thoughts Chuck,  It works fine with an external 16MHz crystal.

I have been trying the same tests on a Arduino Leonardo board... same results.... works at 16MHz with external xtal,  fails with internal RC clock.  I can upload code via ISP and it runs.... but USB causes failure.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

After my post above I read the data and realised that 32U4 is different to 82/162 that I know about (they do need 8/16MHz crystal) so I edited the post but for the umpteenth time this bloody web site did not store the edit that I posted - sorry for the noise!

Thanks all the same :-)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

After my post above I read the data and realised that 32U4 is different to 82/162 that I know about (they do need 8/16MHz crystal) so I edited the post but for the umpteenth time this bloody web site did not store the edit that I posted - sorry for the noise!

Thanks all the same :-)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More information..... may help...

When the board has just had the boot loader burnt, the computer does not recognise its presence till the first upload of code has taken place  (via ISP).   Its not a reset either as I have tried power on reset after the boot loader burn.  Once the fist upload has happened, then the board runs (flashing LED's in a sequence) and the computer can read the vendor id etc when you look at the system information. But the moment I try to upload code via the USB, the programmer fails saying that it can't find the device.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the programmer fails saying that it can't find the device.

I assume OS-X has lsusb - what does it say?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before software switch to LS

Arduino Micro   :

  Product ID:    0x8037

  Vendor ID:    0x2341

  Version:     1.00

  Speed:    Up to 12 Mb/sec

  Manufacturer:    Arduino LLC

  Location ID:    0x14300000 / 21

  Curre software switch to LS

 

Then after running this:

UDCON |= (1 << LSM);
  PLLFRQ |= (1 << PINMUX);
  PLLCSR |= (1 << PLLE);
  delay(100); //allow PLL to lock
  USBCON |= (1 << USBE);
  USBCON |= (1 << OTGPADE);

 

Arduino Micro   :

 

  Product ID:    0x8037

  Vendor ID:    0x2341

  Version:     1.00

  Speed:    Up to 1.5 Mb/sec

  Manufacturer:    Arduino LLC

  Location ID:    0x14300000 / 22

  Current Available (mA):    500

  Current Required (mA):    500

 

So it looks like I can switch it to Lo Speed in software, but the boot loader sets it to Hi Speed for uploading??

Last Edited: Fri. Nov 7, 2014 - 11:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK problem sorted.  New .hex boot loader file is required to take account of the lower speed.
Board now working on internal RC oscillator only.  USB communication all OK.

Thanks for all your time :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Uno bootloader is a modified version of the LUFA CDC Bootloader. This uses the CDC-ACM USB class to emulate a virtual serial port, and requires Bulk type USB endpoints.

 

If the internal R/C oscillator in the U4 devices is used, you can only select USB Low Speed (not the faster Full Speed) USB mode. In Low Speed mode, only Interrupt type endpoints can be used with bank sizes of 8 bytes, so it is incompatible with pretty much every standard USB class except the HID class used for mice and keyboards. If you use Low Speed mode, you cannot make a compliant CDC-ACM device.

 

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

paulburger wrote:

New .hex boot loader file is required to take account of the lower speed.
Board now working on internal RC oscillator only.  USB communication all OK.

 

What boot loader did you use that works using the internal RC oscillator (USB low speed)?

 

Last Edited: Sat. Nov 8, 2014 - 07:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

abcminiuser wrote:

The Uno bootloader is a modified version of the LUFA CDC Bootloader. This uses the CDC-ACM USB class to emulate a virtual serial port, and requires Bulk type USB endpoints.

 

If the internal R/C oscillator in the U4 devices is used, you can only select USB Low Speed (not the faster Full Speed) USB mode. In Low Speed mode, only Interrupt type endpoints can be used with bank sizes of 8 bytes, so it is incompatible with pretty much every standard USB class except the HID class used for mice and keyboards. If you use Low Speed mode, you cannot make a compliant CDC-ACM device.

 

- Dean

Thanks for your input Dean (although I am sorted now).

Just to clarify, I was trying to burn a boot loader onto a Leonardo or Micro board to test before burning onto my custom PCB, not an Uno.   The Uno was only used as an ISP programmer.  Once the boot loader was burnt onto the Leonardo/Micr/ATmega32U4 board, then coded/sketches was to be uploaded via the direct USB connection.

 

Interestingly, the ATmega32U4 data sheet clearly states that only Low-speed USB can be used with the internal RC... yet it still seems to work at the 12MHz hi-speed. (Unless they meant 480MHz was hi-speed - or is that full-speed, need to check my nomenclature)

 

The USB will only be used as a field updating route so any form of correct compliancy is not required.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:

 

paulburger wrote:

 

New .hex boot loader file is required to take account of the lower speed.
Board now working on internal RC oscillator only.  USB communication all OK.

 

 

 

What boot loader did you use that works using the internal RC oscillator (USB low speed)?

 

 

Someone kindly recompiled/built the Caterina boot loader from source code after making a couple of small tweaks: changed F_CPU in the makefile to 8000000 and configured the PID/VID, as well as checking that the code did not rely on any fuses related to the clocks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

paulburger wrote:

Interestingly, the ATmega32U4 data sheet clearly states that only Low-speed USB can be used with the internal RC... yet it still seems to work at the 12MHz hi-speed. (Unless they meant 480MHz was hi-speed - or is that full-speed, need to check my nomenclature)

 

It will still "work", but the R/C oscillator drift and accuracy is not within the USB specification's tolerances. Difference batches of devices, different hosts and/or varying voltage and temperature will cause unreliable communications.

 

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

It will still "work", but the R/C oscillator drift and accuracy is not within the USB specification's tolerances. Difference batches of devices, different hosts and/or varying voltage and temperature will cause unreliable communications.

Fair point.

 

I'm happy to stick with Low Speed (1.5Hz) for my application.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

Guys, I have the same problem like the author but he's solutions still doesn't work for me. I can't understand where is the mistake...

So, a part of my code is:

/*Switch from external clock to RC clock*/ 
if(SUSPI == 1)//bit in UDINT reg 
{ 
  UDINT = (0 « SUSPI); 
  USBCON = (1 « FRZCLK); 
  PLLCSR = (0 « PLLE); 
  CLKSEL0 = (1 « RCE); 
  while (RCON != 1);//bit in CLKSTA reg 
  CLKSEL0 = (0 « CLKS); 
  CLKSEL0 = (0 « EXTE); 
} 
PLLCSR = (0 « PINDIV)|(1 « PLLE); 
PLLFRQ = (1 « PINMUX)|(0 « PLLUSB)|(0 « PDIV3)|(1 « PDIV2)|(0 « PDIV1)|(0 « PDIV0); 

//?: I don't know should i do this
USBCON = (0 « FRZCLK); 
USBCON = (1 « USBE); 

USB_Init(); 
/*OSCCAL = 112 => f~8MHz*/ 
OSCCAL = (0 « CAL7)|(1 « CAL6)|(1 « CAL5)|(1 « CAL4)| 
(0 « CAL3)|(0 « CAL2)|(0 « CAL1)|(0 « CAL0);

Does someone have an example of using lufa in low level? Or may be you see a mistake in my code or something else?..

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am also trying to get a LUFA bootloader to run on a Atmega32u4 chip that uses the internal RC oscillator. I tried changing F_CPU to 8000000, setting the PID and VID and replacing USB_DEVICE_OPT_FULLSPEED with USB_DEVICE_OPT_LOWSPEED in LUFA_OPTS, but while compiling finishes without issues, when I upload the .hex to the chip, the USB connection does not work (port is visible in Arduino IDE, but uploading gives the following error: jssc.SerialPortException: Port name - /dev/cu.usbmodem1411; Method name - openPort(); Exception type - Port busy). What I get is a pulsating output on LED_BUILTIN pin (D13, pin 32). I tried to find an explanation for the blinking and find debugging instructions, but was unable to find anything useful. Any ideas as to what might be causing the issues? Any tips on where to find more information on the errors and debugging?

 

paulburger wrote:

Chuck99 wrote:

 

paulburger wrote:

 

New .hex boot loader file is required to take account of the lower speed.
Board now working on internal RC oscillator only.  USB communication all OK.

 

 

 

What boot loader did you use that works using the internal RC oscillator (USB low speed)?

 

 

Someone kindly recompiled/built the Caterina boot loader from source code after making a couple of small tweaks: changed F_CPU in the makefile to 8000000 and configured the PID/VID, as well as checking that the code did not rely on any fuses related to the clocks.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was actually able to get the board to work with a bootloader I downloaded from https://www.eevblog.com/forum/mi... (Caterina.hex). I still am unable to make my own bootloaders to work although I had more success with using the CDC bootloader example in the latest release of LUFA. With that bootloader I was able to upload an application to the microcontroller once after burning the bootloader using Arduino IDE for both. After the first upload however, it seems that the bootloader code is not run or it does not wait for an upload to start but instead executes the application immediately after boot.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you haven't set the fuses for bootloader use then. You either need BOOTRST or HWBE/HWB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have BOOTRST  enabled and HWBE disabled + !HWB connected to ground. Afaik this should make the controller always jump to the bootloader address on boot. I have the fuses set as follows:

 

micro_int.bootloader.low_fuses=0xe2
micro_int.bootloader.high_fuses=0xd8
micro_int.bootloader.extended_fuses=0xfb

 

Although I was able to get the device to show up as a USB device in the System Information app, this no longer works. All I get after burning the bootloader is a flashing LED_BUILTIN. Any advice on how to get the board to work / how to debug the issue?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, here's the rest of the entry on boards.txt:​

 

micro_int.name=Standalone Micro
micro_int.vid.0=0x03eb
micro_int.pid.0=0x204a

micro_int.upload.tool=avrdude
micro_int.upload.protocol=avr109
micro_int.upload.maximum_size=28672
micro_int.upload.maximum_data_size=2560
micro_int.upload.speed=57600
micro_int.upload.disable_flushing=true
micro_int.upload.use_1200bps_touch=true
micro_int.upload.wait_for_upload_port=true

micro_int.bootloader.tool=avrdude
micro_int.bootloader.low_fuses=0xe2
micro_int.bootloader.high_fuses=0xd8
micro_int.bootloader.extended_fuses=0xfb
micro_int.bootloader.file=caterina-internal/caterina-eevblog.hex
micro_int.bootloader.unlock_bits=0x3F
micro_int.bootloader.lock_bits=0x2F

micro_int.build.mcu=atmega32u4
micro_int.build.f_cpu=8000000L
micro_int.build.vid=0x03eb
micro_int.build.pid=0x204a
micro_int.build.usb_product="Standalone Micro"
micro_int.build.board=AVR_LILYPAD_USB
micro_int.build.core=arduino
micro_int.build.variant=leonardo
micro_int.build.extra_flags={build.usb_flags}