Problems with 32U4 custom design

I’m wondering if someone might be able to point me in the right direction here. Attached to this post is a schematic using a 32U4 MCU that I built on a custom designed board. The problem I have now is that I can’t seem to get AS6 (with an mkII) to read the device ID. When I go in Device Programming, it fails with:

Code:

[ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.)

That’s a bit cryptic for me. It does read voltage just fine.

I also don’t know if connecting it to USB should cause it to enumerate on the computer (if it should, then it’s not right now.) I can’t see how nor why since this is a brand new IC from Mouser, unless they (or Atmel) puts something on them prior to shipping them out.

It is entirely possible that I made a big mistake, however I can’t figure out what. I did forget to add status LEDs on anything so that will be for revision 2 …

Ultimately what I’m trying to accomplish here is burn the Arduino Leonardo bootloader on it by loading the Leonardo hex file in AS6 then programming the 32U4, but I can’t even get it to recognize the device.

Any hints?

is the 16MHz XTAL oscillating OK ?

How can I test that (I don’t have a scope)? I built two separate boards and they’re both doing the same thing.

short wave radio tuned to 16MHz ?

6th harmonic of 16MHz is 96MHz which is within the FM band - listen for silence-in-the-noise with the radio next to the unit

also check C3 and C4 are correct values - they will stop the crystal from running if they are too far off

How much current is the unit consuming at 5V - check the data sheet for a Freq + voltage against current curve. I would guess it should be drawing at least 20mA if the osc is running.

Does 5V rail current change if you short out the xtal ?

add scope to XMAS wish list :slight_smile:

-mark

Yeah no kidding, desperately need a scope. However, someone over on the avrfreaks forums pointed out one thing I completely overlooked: the HWB pin. I didn’t connect it to anything. The genuine Arduino Leonardo has that pin permanently grounded through a series 10K resistor. So I’m wondering if that’s the issue here. I’m going to have to figure out how I’m going to short it as I used the MLF package where all the pads are under the IC. I have about 1/2 of a millimeter sticking out from under it so I’m going to try and ground it and see what happens. Urgh!

Yup, but I think you still need the Xtal to be running.

HWB is only sampled if the associated fuse bit (HWBE) is set in the “Extended Fuse Byte”

32U4 has this bit set to 0 from the factory, 32U4RC has this bit set to 1 from the factory.

Which version do you have ?

Even now, I think you still need the Xtal to be running.

mark

The non-RC one, QFN44 with exposed pad (some refer to it as an MLF package as well, but I think MLF doesn’t have an exposed pad.) Without a scope, I have no way to test the crystal so I guess I’ll have to go do the radio trick. Am I listening for something, or just dead silence?

hopefully the radio will produce noise when not tuned to a radio station. When you find a signal, the noise should quieten.

Also check 5v current, with and without the XTAL shorted out (tweezers, pliers etc.)

What should I be shorting, the XTAL1 and XTAL2 pins, or XTAL1/2 to GND?

(Haven’t tried radio trick yet, about to)

short XTAL1 and XTAL2 will stop the oscillator. If 5V current drops significantly, then it may well have been oscillating. A small change indicates that the XTAL was probably not running.

It’s hard to short the darned thing because I can’t get to the pads easily. But everything I tried resulted in nearly no change, which could translate in the thing not oscillating. Doing the FM radio test got me nowhere mainly because it’s an analog radio and setting it to 96MHz proved to be futile - I heard no difference when scanning through a short range either, whether the unit was running or not. Possibly another strike.

Going back to my BOM, the crystal is rated for 20pF and I realized now that the capacitors on it are 18pF. The datasheet on the crystal says a minimum of 10pF, typical 20pF, maximum 20pF. So, I guess the next step is to replace the caps with 20pF versions and cross my fingers. Considering they’re 0402 size, this is going to be fun I’m sure.

Question, if I don’t ground the HWB pin (ever), should the MCU do something regardless when I plug in a USB cable and power it up (assuming the crystal is working)? Or will it not do anything at all?

The HWB pin appears to select between one of two sets of ROM/FLASH to jump to at power up. The contents of the memory decides how the system, behaves. I doubt if plugging the USB in with an un-programmed device is likely to do very much.

As long as you really do have 18pF loaded, then leave well alone. Problems occur when a 100n gets loaded by mistake, and the XTAL has no chance of operating.

Do you have a friend with a scope ?

I would still put next effort into verifying that the XTAL is running OK before you go any further - having said that, does the part have a fallback RC system clock ? Need to check the datasheet fully.

-mark

I’m trying to figure out how I can ground the HWB pin seeing as getting to it is going to be rather hard. Drawbacks of using the QFN-EP package. The genuine Leonardo design has that pin permanently grounded through a 10K resistor so I think I’m just going to follow that since ultimately I will have the Leonardo bootloader on this.

As for the caps, what I ordered are 18pF. Possible that Mouser made a mistake? Sure. My DMM is fluctuating too much to get a good reading on them, not to mention they’re rather tiny at 0402. And I don’t have any other parts in my bins that I could swap them with, so I’d have to either a) assume they’re correct, or b) order some new ones, different part numbers perhaps, and swap them. Unless you can think of another fun way to test the oscillator without a scope. I’ll put a call out to some friends, see who might have one I can borrow for an evening.

The part is shipped with Low Power Crystal Oscillator enabled with the CKDIV8 fuse enabled, resulting in a 1MHz clock with an 8MHz crystal. However, in order for me to change that, I need to be able to detect it and I can’t right now.

Your design indicates a 16MHz XTAL, what freq have you actually loaded ?

If you have loaded 16MHz, check the data sheet to make sure “Low Power Crystal Oscillator” will run at that rate using your current supply voltage.

Also read “Low Power Crystal Oscillator” mode and see if there are any other prerequisites.

Yeah, it’s supposed to work just fine. The more I read about it, the more I think it’s all about that pesky HWB pin that I didn’t ground. I have some thin wire wrap that I’m going to try and attach today and see if I can ground it MacGyver style. It’ll be an interesting exercise, if not nearly impossible considering how much of the pad I have available … more like solder that is attached to the very edge of the IC package.

So that didn’t work out. It’s too dang small and there isn’t a whole lot of room to work with. Fiddled with it for a little over a half an hour before finally throwing in the towel. Whether it’s the crystal not resonating or the HWB pin not being grounded, at this point I need to move on. I will likely get a DSO to test these “failed” boards, but in the mean time I’m starting another thread with a revised schematic. Can’t dwell on these things forever now …

Never underestimate the power of a gut feeling.

It took me fiddling with the board in SketchUp (because I’m designing a protective sabot for the boards to go inside of a tube) when something stood out: the crystal pads. While looking at the model, I noticed something odd with it: pin 1 was grounded, as was pin 3. However, the oscillator is on those pins! What gives?! Double, triple checked the datasheet and yep, pins 2 and 4 needed to be grounded, not 1 and 3. Went back to the footprint in EagleCAD and sure enough, the package is flipped. I copied it from a library a while ago so I don’t remember where from, but the original creator designed the package as it is in the datasheet, forgetting that it’s a bottom view and it needed to be flipped.

So, a little bit of hot air to remove the crystal and rotate it 90 degrees. Plugged the unit in and voila, problem solved! Took me 3 days but by golly, I solved the problem! I already fixed the footprint and updated the new revision. I would’ve been rather pissed if I didn’t catch that prior to getting the second revision boards made and discovering things are still not working. Urgh.

Now I can actually start testing the entire board. Hopefully I don’t run into any other problems. Fingers crossed! Mark, thank you for your constant nudging to check the crystal. I just never thought of checking orientation because I made the wrong assumption the land pattern I had was actually correct.