-
We have a custom board based off the atmega32u4, with an external 16MHz crystal oscillator. (Schematic attached)
Using the Arduino framework for ease.
At present we use the Leonardo bootloader, but have also used the Sparkfun Pro Micro one as well.
The history is that we made a batch of these boards to test them, they all worked perfectly. Connect seamlessly to Windows, ChromeOS & Mac and show up as serial ports.
Then we made a larger batch, now, these new boards connect fine on Windows & ChromeOS, but they don’t connect to Mac.
Thoughts i’ve had, with their counter argument:
- It’s a Mac issue - So why do the old batch, with exactly the same code on them work perfectly on Mac? (I’ve tried flashing an old batch and new batch straight after each other with the same code and only the old batch works)
- It’s a processor problem - But they work perfectly on Windows?
- It’s a USB connector problem - But they work perfectly on Windows?
- Clock speed problem, maybe Windows is more tolerant of clock discrepancies? - Hooked up to an oscilloscope and both the old batch and new batch are reading 16MHz
If anyone has any advice for things to check I'd be most grateful.
Even advice on other forums / areas i could post on.
Many thanks and much love / coffee / beer / cold hard cash to anyone that can point me in the right direction.
-
Same bootloader and fuses? Same cable?
-
Yep, same bootloader, same fuses, same cable. So confusing!
-
Ok noob on mac is there an equivalent of device manager / drivers issues informations ??
Throw away the Mac loll
-
It seems that there must be something physically different with the new boards.
-
Are you programming the same USB device descriptor in the new boards as the old ones?
-
Sadly, throwing the Mac away isn't an option! And no driver issues as the exact same hardware from batch 1 connects perfectly.
Yes, I feel like there must be some subtle difference in the hardware, but have no idea what. Visual inspection shows all the components to be the same.
And yes, all descriptors the same. Literally loaded a batch 1 and batch 2 identically straight after the other!
Any other ideas? Things I can test? -
didn't you update the macos system between the batches ?
-
No updates, and batch 1 continues to work on the same Mac, batch 2 doesn't
-
Where are you sourcing the chips? Is there a possibility that the 32u4 in batch 2 is fake?
Once you're stuck on the easy parts, you could desolder a batch 1 and batch 2 microcontroller and swap them to the opposing board to divide the problem into "it's the board" vs "its the controller". -
Where are you sourcing the chips? Is there a possibility that the 32u4 in batch 2 is fake?
Doesnt even need to be fake, that part has revisions with known USB issues. -
I did had an 32u4 board from sparkfun, it had a slightly different bootloader ??
-
Once you're stuck on the easy parts, you could desolder a batch 1 and batch 2 microcontroller and swap them to the opposing board to divide the problem into "it's the board" vs "its the controller".
That is a good idea, slightly outside my current skillset (and available tools). But it's worth buying a hot air reflow tool and trying.Doesnt even need to be fake, that part has revisions with known USB issues.
Do you happen to have a source for this? Would love to be able to just check a list and put all this to bed. Still no idea why it would only affect Mac though!I did had an 32u4 board from sparkfun, it had a slightly different bootloader ??
Yep, they are very slightly different, but not enough to cause issue. Besides, both batch 1 and 2 are on the same bootloader and we still have the difference in behaviour. -
In your first post, you said you use the Leonardo bootloader, but have used the Pro Micro bootloader. Is it possible that the old and new parts actually do have different bootloaders? Or different fuses? Something like that, or a different ID number of some kind, has to be the most likely explanation since the new boards do work with Windows. It's just unlikely to be a hardware defect, but of course not impossible.
-
In your first post, you said you use the Leonardo bootloader, but have used the Pro Micro bootloader. Is it possible that the old and new parts actually do have different bootloaders? Or different fuses? Something like that, or a different ID number of some kind, has to be the most likely explanation since the new boards do work with Windows. It's just unlikely to be a hardware defect, but of course not impossible.
I wish.
We've literally flashed the same bootloader, same fuses, same USB ids on a board from batch 1 & then immediately a board from batch 2. Same outcome, no connecty on Mac. -
So your board powers up, but the Mac doesn't see any device present on USB at all. Does your board have a reset button? Does pushing that make any difference? If you flash the Blink example sketch to your board, does that make any difference? Just grasping at straws here.
-
So your board powers up, but the Mac doesn't see any device present on USB at all. Does your board have a reset button? Does pushing that make any difference? If you flash the Blink example sketch to your board, does that make any difference? Just grasping at straws here.
Yes, powers up, i even made a test code to ensure that the code was actually running when plugged in.
I do have a reset button, and if i press it i do get a number of things happen. Please note this is usually after doing like 10 presses or some double presses, it's very inconsistent:- very very rarely the device will show up on the Mac, but then very quickly disappear again
- it'll just do its normal startup thing, but no connection to mac
- it'll almost get stuck doing its startup thing over and over - i've thought about this and low-power, or crashing etc? But why only on Mac?
-
Does the new batch of boards have any changes from the original batch. Different parts, different manufacturers of the same part, different routing? Any changes at all.
So I guess if it were me I would first try measuring resistances on the old and new unpowered boards to see if they match. That would be to see if the wrong part has been populated, such as R13 and R14, or something like a diode has been placed backwards.
Then, or maybe first, on the Mac I would see if the voltage on Vbus is the same on the old and new boards.
All else failing, I would have to consider switching the 32U4s to see if that makes the new board work and the old board fail.
-
Normally, I would expect a cap from /RESET to GND to ensure there was a long enough reset pulse at start up.
-
Does the new batch of boards have any changes from the original batch. Different parts, different manufacturers of the same part, different routing? Any changes at all.
So I guess if it were me I would first try measuring resistances on the old and new unpowered boards to see if they match. That would be to see if the wrong part has been populated, such as R13 and R14, or something like a diode has been placed backwards.
Then, or maybe first, on the Mac I would see if the voltage on Vbus is the same on the old and new boards.
All else failing, I would have to consider switching the 32U4s to see if that makes the new board work and the old board fail.
No changes at all.
Only difference in resistance i could see was that R21 (which should be 10k) reads 9.69k on the working board and 9.60k on the non-working board. But not sure if that could cause this?
Vbus identical on both boards, so not that either.
Gearing up to swap the ICs now, with much trepidation!
ACTUALLY, HUGE UPDATE!!!!
I my nervousness to switch ICs i did a bit more googling and decided to try some of the more weird suggestions i found...
Plugging in my board via a USB 2 hub makes the board work and is recognised every time i plug it in.
So i'm thinking it's some sort of USB versioning issue?
(Note it's an unpowered hub, so power isn't a factor) -
Well, I'm confused. You said the old boards worked on the Mac. Were you using a different port on the Mac for the new boards? Anyway, the 32U4 is USB 2.0 only.
-
Plugging in my board via a USB 2 hub makes the board work and is recognised every time i plug it in.
This was a well known issue with the first USB 3 host implementations with ATmega32u4 and other USB 2 devices that only support USB 1.1 speeds, i.e. 1 Mbit/s (LS) or 12 Mbit/s (FS). I saw this myself with both ATmega32U4 and AT90USB1280.So i'm thinking it's some sort of USB versioning issue?
USB 3 has separate D+ and D- pins for USB 2.0 and 1.1, and SSRX+, SSRX-, SSTX+, and SSTX- pins for USB 3 and later (with just pin names changing for the type C connector).
The issue is that some USB 3 host chipsets (or possibly drivers) have an issue detecting USB 1.1 devices, i.e. USB 2.0 at 1 Mbit/s (Low Speed) or 12 Mbit/s (Full Speed), and really "prefer" USB 2.0 at 480 Mbit/s (High Speed) or USB 3 or later. I suspect, but have no proof or references, that this is due to the fact that USB 2.0 at 480 Mbit/s requires retiming of the D+ and D- signals to reduce jitter, but not at LS or FS, and somehow the USB 2.0 implementation on these USB 3 host ports fail to correctly detect USB 2 LS or FS devices. (This means that you have the same issue if you use a cheap USB 2.0 LS or HS isolator, like those based on ADUM3160 and 4160, also fixed by using a hub in between the host and isolator.)
When you connect an USB 2.0 hub that supports HS, 480 Mbit/s –– and basically they all do ––, I suspect the retiming of the signals is what fixes the issue. In all cases of USB 3 and USB LS/FS device issues, an USB 2 hub in between has solved the issue (except for actual broken hardware, that is).
Fortunately, adding the hub in between, has basically no downsides. I personally use a cable one for my USB 2.0 LS/FS microcontrollers, that also happens to act as my USB A to USB micro-B cable, with an el-cheapo eBay $10 ADUM3160 USB isolator between the cable hub and my host computer, whenever I'm poking at pins or breadboarding, mostly to calm my nerves (me being a sausage-fingered uncle bumblefcuk), but also to ensure my host computer USB ports will always be safe and I am in no danger of ground loops or injecting current/voltage back to my computer.
(Now that USB 2.0 HS isolator chips have become affordable (and really only need an additional 24 MHz crystal, and a couple more capacitors compared to the LS/FS chips), I've been thinking about making my own isolator with selectable power lines so that I can use isolated wall warts to supply up to 2A, or host USB 5V via DC-DC converter (drawing max. 500mA from upstream, so typically max. 400mA downstream). My Teensy 4 are USB 2.0, but do support HS, 480 Mbit/s; nice. As these isolators do the retiming of the signals based on the 24 MHz crystal, no hub is needed.) -
Wow, thanks for the in-depth explanation.
Only slight outstanding things for me are:
a) the "older" boards with exact same hardware work without the hub (as PeaBody mentions above (yes was doing all testing on the same port))
b) actually, even though the board is recognised and i can interact with it over serial, when i go to program the new boards with Arduino, it disappears form the list of devices, even when on the hub. So maybe an issue going into bootloader mode when triggered by USB? -
I find several issues on your board.
1. Don't connect USB Shield to ground. Use 100n||330R as a filter.
2. Your TVS protection will pass -5V pulses, which will kill the chip. You want to use unidirectional TVS diodes, not bidirectional ones. Suggestion: Wuerth WE-8240026. This is a SOT143 part that protects D+, D-, and VBUS.
3. A ferrit between VBUS and +5V for the rest of the system reduces noise: Suggestion BLM18SP601SN1D.
4. Is the highes brownout level enabled?