Mixing
How to test for USB dropouts on STM32F?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I've got a devices that is really strange, it drops USB periodically. By periodically I mean on a weekly (or biweekly) basis. By dropping out I mean windows loses the handle to the driver. Dropouts a not tolerated well by those using the devices. The weird thing is I use a similar design on most of the products that we have (more on that later), for some reason this one doesn't want to play nicely, some of the other devices run for months to years (with the same design but different layout) with zero issues.
It's only on some of the devices so that probably rules out firmware/software.
The USB is 2.0 FS, running to an STM32, with an ESD diode chip in the middle.
Schematic (D+ and D- and OSC_IN and OSC_OUT (oscillator design was inherited) go to their corresponding pins)
A better question would be, how do I test for these dropouts? Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?
usb stm32 usb-device test
asked Aug 14 at 2:48
laptop2d
20.5k123071
 |Â
show 6 more comments
up vote
4
down vote
favorite
I've got a devices that is really strange, it drops USB periodically. By periodically I mean on a weekly (or biweekly) basis. By dropping out I mean windows loses the handle to the driver. Dropouts a not tolerated well by those using the devices. The weird thing is I use a similar design on most of the products that we have (more on that later), for some reason this one doesn't want to play nicely, some of the other devices run for months to years (with the same design but different layout) with zero issues.
It's only on some of the devices so that probably rules out firmware/software.
The USB is 2.0 FS, running to an STM32, with an ESD diode chip in the middle.
Schematic (D+ and D- and OSC_IN and OSC_OUT (oscillator design was inherited) go to their corresponding pins)
A better question would be, how do I test for these dropouts? Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?
usb stm32 usb-device test
asked Aug 14 at 2:48
laptop2d
20.5k123071
1
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
1
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
1
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
1
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
1
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27
 |Â
show 6 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I've got a devices that is really strange, it drops USB periodically. By periodically I mean on a weekly (or biweekly) basis. By dropping out I mean windows loses the handle to the driver. Dropouts a not tolerated well by those using the devices. The weird thing is I use a similar design on most of the products that we have (more on that later), for some reason this one doesn't want to play nicely, some of the other devices run for months to years (with the same design but different layout) with zero issues.
It's only on some of the devices so that probably rules out firmware/software.
The USB is 2.0 FS, running to an STM32, with an ESD diode chip in the middle.
Schematic (D+ and D- and OSC_IN and OSC_OUT (oscillator design was inherited) go to their corresponding pins)
A better question would be, how do I test for these dropouts? Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?
usb stm32 usb-device test
asked Aug 14 at 2:48
laptop2d
20.5k123071
I've got a devices that is really strange, it drops USB periodically. By periodically I mean on a weekly (or biweekly) basis. By dropping out I mean windows loses the handle to the driver. Dropouts a not tolerated well by those using the devices. The weird thing is I use a similar design on most of the products that we have (more on that later), for some reason this one doesn't want to play nicely, some of the other devices run for months to years (with the same design but different layout) with zero issues.
It's only on some of the devices so that probably rules out firmware/software.
The USB is 2.0 FS, running to an STM32, with an ESD diode chip in the middle.
Schematic (D+ and D- and OSC_IN and OSC_OUT (oscillator design was inherited) go to their corresponding pins)
A better question would be, how do I test for these dropouts? Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?
usb stm32 usb-device test
asked Aug 14 at 2:48
laptop2d
20.5k123071
edited Aug 15 at 5:23
asked Aug 14 at 2:48
laptop2d
20.5k123071
asked Aug 14 at 2:48
laptop2d
20.5k123071
asked Aug 14 at 2:48
laptop2d
20.5k123071
20.5k123071
1
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
1
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
1
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
1
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
1
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27
 |Â
show 6 more comments
1
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
1
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
1
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
1
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
1
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27
1
1
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
1
1
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
1
1
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
1
1
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
1
1
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27
 |Â
show 6 more comments
3 Answers
3
active
oldest
votes
up vote
11
down vote
accepted
Is there some method that could monitor a device for very long periods
of time with millions of packets going by and find the source of the
error?
Yes. The device is called "USB protocol analyzer".
If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.
There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.
However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).
So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.
I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.
If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
add a comment |Â
up vote
4
down vote
I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
add a comment |Â
up vote
1
down vote
We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips.
So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.
answered Aug 15 at 10:19
nighthawk
192
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
Is there some method that could monitor a device for very long periods
of time with millions of packets going by and find the source of the
error?
Yes. The device is called "USB protocol analyzer".
If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.
There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.
However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).
So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.
I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.
If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
add a comment |Â
up vote
11
down vote
accepted
Is there some method that could monitor a device for very long periods
of time with millions of packets going by and find the source of the
error?
Yes. The device is called "USB protocol analyzer".
If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.
There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.
However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).
So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.
I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.
If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
add a comment |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
Is there some method that could monitor a device for very long periods
of time with millions of packets going by and find the source of the
error?
Yes. The device is called "USB protocol analyzer".
If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.
There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.
However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).
So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.
I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.
If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
Is there some method that could monitor a device for very long periods
of time with millions of packets going by and find the source of the
error?
Yes. The device is called "USB protocol analyzer".
If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.
There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.
However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).
So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.
I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.
If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
answered Aug 14 at 4:27
Ale..chenski
22.8k11756
22.8k11756
add a comment |Â
add a comment |Â
up vote
4
down vote
I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
add a comment |Â
up vote
4
down vote
I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
add a comment |Â
up vote
4
down vote
up vote
4
down vote
I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
answered Aug 14 at 8:18
Dirk Bruere
4,90622553
4,90622553
add a comment |Â
add a comment |Â
up vote
1
down vote
We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips.
So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.
answered Aug 15 at 10:19
nighthawk
192
add a comment |Â
up vote
1
down vote
We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips.
So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.
answered Aug 15 at 10:19
nighthawk
192
add a comment |Â
up vote
1
down vote
up vote
1
down vote
We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips.
So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.
answered Aug 15 at 10:19
nighthawk
192
We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips.
So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.
answered Aug 15 at 10:19
nighthawk
192
answered Aug 15 at 10:19
nighthawk
192
answered Aug 15 at 10:19
nighthawk
192
answered Aug 15 at 10:19
nighthawk
192
192
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f390918%2fhow-to-test-for-usb-dropouts-on-stm32f%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
It's only on some of the devices so I think it's hardware related.
– laptop2d
Aug 14 at 2:54
1
"with an ESD diode chip in the middle" sounds very suspicious.
– Ale..chenski
Aug 14 at 4:35
1
Do you capture and log the system exceptions? (eg: hardfaults)
– Jeroen3
Aug 14 at 6:14
1
As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices?
– Ale..chenski
Aug 14 at 20:08
1
BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication.
– Ale..chenski
Aug 14 at 21:27