Teensy 3.1 - "USB Device Not Recognized" - HELP!

Status
Not open for further replies.

tom.fleet

New member
Hi All,

I have an apparent problem with the USB connectivity of the Teensy 3.1 Boards.

I am using them to drive a large number (1920) of WS2812B pixels, using the OctoWS2811 Library.

My hardware setup is as follows;
1) 1 x Teensy 3.1 Board, buffered with a 74HC245 for 5V compliance.
2) 1920 WS2812B LED Chips, arranged in a set of 8 x 240 LEDs, where each set of 240 is arranged in a set of 4, 60 LED strips, in a "zig-zag" fashion
3) 2 x 320W 5V SMPS PSU.

I have had this setup working nicely using both OctoWS2811, *and* the NeoPixel libraries. This is the 2nd time however that I have observed a NTeensy 3.1 fall into an "unrecognized" state. I assumed that the first time I had this happen, I must have shorted something without noticing. However, having had this occur twice , with the 2nd Teensy fully enclosed and protected from shorts, I'm not so sure any more!

Observations;
1) I can see all voltage rails running at their correct levels.
2) I can observe the oscillator package running at 16MHz, at approx. 1Vpp.
3) I can observe USB traffic on both D+ and D- (scoped at the series resistors adjacent to the micro-USB connector, and on the D+/D- pads on the underside of the Teensy PCB.

Troubleshooting:
1) Reset button and driving of it's connected pin on the PCB has no effect.
2) Driving the reset pad, located on the underside of the board has no effect.
3) Windows 7/8.1 both report unrecognized device (both machines have been sucessfully used for teensy development before).
4) Running "lsusb" on my rPi setup (used for FadeCandy) shows no devices listed in relation to the Teensy.

Final Comments / Thoughts
1) Both times I have seen these boards fail, it has been during a session of intense code uploading / serial activity.
2) I am very careful to sequence power correctly; I am only powering half of my array at the moment, but I ensure that the load is manually disconnected before switching off the supply, etc. I would also have hoped that the 74HC245 would have provided *some* protection against serious spiking...
3) Although this is a hobby of mine, I am an embedded electronics engineer by day, with a basis in R&D; Thus, I am confident in my asessment of the current situation!
4) *once* last night, I was able to load the "Blink" sketch, which appeared to bring everything back to life. This is not possible any more it seems!

I suspect that the Teensy is still actually operational (ie, *not* physically damaged). Paul, is there any way for me to dig a little deeper into the operation of the board? I'm used to working with Atmel SAM devices, using a full debugger and IDE setup. I'm finding troubleshooting a little difficult with the limited arduino IDE, and more importantly, I have a client waiting for this project, having already had to wait for me to re-build this controller once already!

*Any* thoughts and feedback are greatly appreciated!

Many Thanks,

Tom Fleet
 
Troubleshooting:
1) Reset button and driving of it's connected pin on the PCB has no effect.
2) Driving the reset pad, located on the underside of the board has no effect.

I'm trying to understand "no effect".

When the PROGRAM signal goes low, the Mini54 chip should bring the RESET signal low.

When RESET is held low, the MK20 should not have any USB activity, because it's being held in the reset state.

Does "no effect" mean the USB activity continues and RESET doesn't go low while PROGRAM is low?

3) Windows 7/8.1 both report unrecognized device (both machines have been sucessfully used for teensy development before).

Seeing an unrecognized device in the Windows Device Manager usually means Teensy is working, but something is wrong on the Windows side. A dead Teensy will not show up at all. To be in the device manager list as unrecogized, it needs to complete the USB enumeration process, which requires responding correctly to lots of query from the PC.

If you open the properties for the unrecognized device, is there any info in any of the tabs? Perhaps a "Hardware-Id" in the advanced tab?
 
Hi Paul,

(Nice to finally talk to you, long time fan of what you've done with the Teensy platform)

Thanks for the prompt response, I know what it's like dealing with multiple time zones!

Allow me to clarify, in response to your queries.

1) "No effect" is intended to mean that pressing the PROGRAM button / driving the pin temporarily whilst powered, shows no effect on the behaviour observed. That is, the Teensy does not recover.

2) USB activity does not continue with the PROGRAM signal driven low.

3) USB activity is observed on my Tek' up untill the point whereby windows reports an Unrecognized Device.

UPDATE;

Somehow, In probing about on the USB Series resistors to the K20 (it is my understanding that the USB connects to the K20 itself, which is loaded with a boot-loader by the MINI on PROGRAM?), TeensyLoader kicked into life with its verbose output, and I've just managed to upload my sketch. I shall be inspecting the board for a possible dry joint under the microscope later, but I'm not convinced that I hadn't managed to lock the board up somehow.

I will keep this thread up to date with any more findings.

Again, Paul, thanks for picking this up so quickly, your point that even an unrecognized device must still have gone through some form of enumeration was a much-needed sanity check!
 
Another Teensy 3.1 - "USB Device Not Recognized"

Dear Paul, Dear Tom,

I have the same issue as explained by Tom.
After intense code uploading the USB connection failed and did not recover yet.

Troubleshooting
Reset button has no effect.
Power-down of Teensy 3.1 for > 1hr has no effect.
I was unable to reproduce the magic handling from Toms last post, where he probed the USB Series resistor.

Configuration
I connect the Teensy 3.1 over USB with a Win 8.1 64 bit computer.

USB Failure messages
When in failure mode the Win 8.1 device manager provides the following information:

---
Unknown USB device (error requesting a device description.)
Device type: USB-Controller
Manufacturer: (Standard-USB-Hostcontroller)
Location: PORT_#0003.Hub_#0003

Device status:
This device has been paused because it has reported problems. (Code 43)
Error on a request of the USB device descriptor.
---

Is there anything else I could do to get away from the error situation.
Thank you in advance for your feedback.

Andreas

===< UPDATE >===============

The Reset-button is your friend ...
I was able to load an run the "blink.ino" program onto a Teensy3.1.
I was able to load an run the more complex "Teensy_Adafruit_Touch_Test" program onto a Teensy3.1 with connected ILI9341.

I was NOT able to load and run my own program.
This made me believe, that something in my own program is wrong.

As a next step I will try to find the buggy software part.

===< UPDATE 2>===============
I was able to write a short test program to reproduce the error as follows.
The constructor calls a function "init".
If uncommented this causes the issue.
Otherwise the program runs as expected.

The scheme worked for Arduino UNO, however under Teensy it causes problems.

Any thoughts?

/*
Teensy 3.1 Sample code to reproduce USB error
*/
//-----------------------------------------------
class tstDbg {
public:
tstDbg();
~tstDbg();

void dbgOut(void);
void init(void);
}; //-----------------------------------------------
tstDbg::tstDbg() {
// init(); //<<== if uncommented causes USB-error
}

tstDbg::~tstDbg() {}

void tstDbg::dbgOut() { Serial.println("dbgTest"); }

void tstDbg::init(void) {
Serial.begin(9600);
Serial.println("tstDbd started ...");
} //-----------------------------------------------
tstDbg mydbg;
//-----------------------------------------------
const unsigned int led = 13;

void setup() { pinMode(led, OUTPUT); }

void loop() {
digitalWrite(led, HIGH); delay(1000);
digitalWrite(led, LOW); delay(200);

mydbg.dbgOut();
}
 
Last edited:
Dear Windows users,

Being in process of developing on the Teensy 3.1 , I have as yourselves hit the "Code 43" problem today.

First of all, I would like to bump the topic to attract as much attention on this weird problem. Also, I would like to write down the steps I did in the hope that it would help to resolve this frustrating issue.

My development environment is:

CPU: Intel i7 x64
OS: Windows 7 Ultimate 64-bit
IDE: Microsoft Visual Studio 2013
Using a nmake makefile to use the compiler and the linker. It also tells the Teensy Loader that a job is ready to be uploaded and then use teensy_reboot.exe

I know for sure that I have not damaged my Teensy 3.1 at all. Following my problems with the Teensy 3.1 I used to testing, I tried uploading my code to a BRAND_NEW Teensy 3.1 and the exact same problems were reproduced.

The development environment worked very well so far and I was very satisfied with that the Teensy 3.1 brought me so far. This morning I hit the Code 43 problem and spent several hours searching for a solution that would work.

So far I have tried:

1) Stopping my laptop computer and removing the battery. I left it for several hours before rebooting it.
This did not solve my issue.
2) I have tried twice this possible fix: http://forum.pjrc.com/threads/23566-Teensyduino-USB-Joystick-no-data-driver-problem-workaround
The specified workaround did not solve my issue at all.
3) I have also tried this possible fix: http://forum.pjrc.com/threads/23616-Code-43-problems-on-Windows
This simply added a COM port that wasnt working. It was like hardcoding a new COM port that wasnt used at all.

Then I tried something that gave me some hope:

1) I download a .hex file of the Blink example.
2) I use the Teensy Loader to upload the Blink .hex file.
3) I reset the Teensy 3.1 and the Blink example runs correctly.
IMPORTANT: At this time, and for the first time since a few hours, Windows did pick up correctly the Teensy 3.1 as a COM device and assigned a working COM port.
4) I then open Arduino IDE and open up EchoBoth.cpp example.
5) I can then upload EchoBoth and I dont need to reset the Teensy 3.1. The Teensy Loader took care of it.
6) I open up Putty and make a connection with the correct baud rate and now accessible COM port. I can now successfully use the serial communication. The program works well.
7) I then try to upload the .hex file of the program I am working on. Windows goes back to crazy mode and tells me that the connected device is unkown. (Device Manager Code 43)
8) I go back to step 4 to make it work.

Notes:
a) The Teensy Loader did not seemed to be an issue. I seemed always able to upload my program using the Teensy Loader.
b) I tried to upload myprogram.hex using the Teensy Loader and it did the same problem as when I was using my IDE, so I dont think the IDE/Makefile is problematic at all.
c) I can send .hex files for investigation.

I just wanted to help out with that issue I am also having, I will continue to investigate and any solution found will be updated here, as a tutorial or a homemade program that would solve the issue.

Thanks for reading,

Phil
 
UPDATE:

I have tried to compile my program using all objects files that Arduino created. Worked like a charm. I then tried several times with the files I am generating. I have been able to pin down what might be the problem. When I am using the Arduino compiled Xbee.o file, there is no problem. But when I try to used my version of the Xbee library that is modified to support DigiMesh in APi 2 mode, it creates the problem of Code 43. I have been able to reproduced this multiple times with 100% reliability to fail/succeed.

UPDATE 2:

I have been able to tackle the problem. The problem was that I was using Serial.println(); inside the XBeeResponse::XBeeResponse() constuctor. That had the effect of messing with the Serial connection in such a way that the "Code 43" problem was systematic with this.

I had, for testing purpose because my Teensy 3.1 was freezing around that :

XBeeResponse::XBeeResponse() {
Serial.println("Constructor fired.");
}

This made the program screw the Serial connection. It seems.

After I remove the Serial.println() call from within the constructor. It worked as it has always been.

As to why a call to Serial.println() within a particular function would completely break any serial connection attempt, I have no idea.
 
The problem was that I was using Serial.println(); inside the XBeeResponse::XBeeResponse() constuctor. That had the effect of messing with the Serial connection in such a way that the "Code 43" problem was systematic with this.

Can you post this as a small but complete program that reproduces the problem?
 
There you go,

I attached a very basic main file. You will want to start your investigation at line 37 of XbeeDM.cpp
The library is an adaptation of the Andrew Rapp Xbee library to support DigiMesh.

The program has been compiled and linked with the Arduino generated .o files.
 

Attachments

  • XBeeDM.h
    30.5 KB · Views: 278
  • main.cpp
    141 bytes · Views: 142
  • XBeeDM.cpp
    38.4 KB · Views: 210
Last edited:
Can you provide either a makefile or put this into a .ino file I can copy into Arduino.

As a general rule, I investigate issues like this when there's complete code to reproduce the problem. I can't tell you how many long hours I've wasted trying to reproduce problems where I only had part of the code and needed to guess the rest or other important details, like how to built it to get the same result.
 
I recently started developing some Teensy code, and I hadn't progressed very far before encountering the "code 43" error. However, I was able to resolve it, although I have no explanation why, or how the device and/or Windows got into whatever state they were in in the first place.

The Troubleshooting page suggests powering down the PC entirely--including, in the case of a laptop, removing the battery. Because my laptop has a built-in battery, it's not easy to remove all power as suggested. However, noticed that the Teensy was still able to download and execute code; I just wasn't able to bring up the serial monitor. So then I continued to work on it a bit more, figuring I'd try to solve the problem later. But when I uploaded a different sketch (which I believe was just one of the "example" sketches from the Arduino library, nothing special), Windows re-detected the USB Serial device and all seemed well again. In fact, I then uploaded the original sketch I was working on--still fine. So far the problem hasn't reoccurred, after much more unplugging, plugging, uploading, etc.

So while I can't provide any insight into the cause, hopefully this solution might help get other people up and running again.
 
A similar problem here.

Putting a Serial.println() in the constructor of a library object caused the dreaded "USB device not recognized" Code 43 error as the Teensy hung.

Removing the Serial.println() from the constructor fixed it.

I presume this is because the library objects are constructed before setup() is called? Thus the object constructors are trying to write to Serial before Serial.begin() has been called.
 
Last edited:
Sad to say that I am having the same problem :( I followed these instructions, no joy http://forums.adafruit.com/viewtopic.php?f=25&t=73768&p=379736#p374186

Why is Teensy so picky in this regard? or is me or my computer? I am using windows 8.1

Out of the blue I started getting this error. I re-installed Teensyduino twice, result is the same. I am attaching some screen captures, hope this will help to figure out my issue.

device manager error.JPGUSB detail tab.JPGUSB driver tab.JPGUSB events tab.JPGUSB general tab.JPG

The only thing I see here usual is in the "Driver" screen shot, I see a "Microsoft Driver", I was expecting to see like FTDI driver or something else. I installed the FTDI driver, I am lost :(
 
Last edited:
Serial.print in object constructors can end up being called before the USB serial is initialized, that is before the Serial object constructor is called. Whas a similar issue not too long ago. If this happens or not depends on the order of statical object constructors in memory after linking, and this is not easy to control.

If this happens the Serial code will most probably fail and device enumeration will fail, most likely under any OS.

So the advice would be "Dont call Serial.print on statically allocated objects"
 
Removing the Serial.println() from the constructor fixed it.

I presume this is because the library objects are constructed before setup() is called? Thus the object constructors are trying to write to Serial before Serial.begin() has been called.

Yes, that's part of the problem. It would be an issue, if another even worse problem didn't come into play first.

The even worse problem is Serial.write(), which is called by Serial.println() to actually send data, is a C++ virtual function. Virtual functions are called using a RAM-based table. If the Serial and Print objects haven't been created yet, that table is just random junk in uninitialized RAM (or maybe it's cleared to all zeros by that point... I'm not sure). So your call to Serial.print() never actually gets any data to the Serial object. Even in the unlikely case the data is a valid address, within several instructions something will go wrong and cause the ARM processor to go into fault mode, and from there the chip can't properly respond to USB enumeration requests from your PC.

This problem is officially known as the C++ static initialization order fiasco. The word "fiasco" is used for a good reason! Sadly, all the good solutions involve techniques that generate much less efficient code than static initialization, and it seems the folks behind C++ language have no intention of ever addressing this.
 
First, do not go down the terrible path of fiddling with Windows drivers!

You do NOT need any special driver for Teensy to be able to program. In its Serial modes, you do need a driver to use the Arduino Serial Monitor. But you don't need that to simply program code like the LED blink. All the programming uses HID, not Serial, and every version of Windows has HID drivers built in. So don't worry about drivers until you can successfully get Teensy programmed with the LED blink example! Fiddling with drivers is a huge distraction.

Why is Teensy so picky in this regard? or is me or my computer? I am using windows 8.1

Well, thankfully Windows 8.1 is at least telling you "Device Descriptor Request Failed". That's *far* better than earlier versions of Windows!

Teensy absolutely does work with Windows 8.1. Many people have used it with 8.1, and I have personally tested on 8.1. I also started testing on Windows 10 today. It definitely does work, so this isn't a problem specific to Windows 8.1.

There's 2 possible causes for this sort of problem.

#1 - As just mentioned, if code is crashing the processor as Windows tries to read the USB descriptors, this is exactly what you'd expect. But if you've never managed to program anything onto your Teensy, it should still have the LED blink we load onto it while testing. And regardless of what bad code has been loaded, after you press the button, it will run the bootloader, which appears as a USB HID device.

#2 - Bad USB cables, hubs or other hardware can cause communication errors. My guess is you've got something like that in play here. That screenshot shows 2 hubs and a special USB host controller.

The most common cable problem is charge-only cables for phones, which don't have any data wires.... but whatever you're using must have data lines, since a bad device is showing up, but failing to properly communicate.

Flaky USB hubs are also sometimes an issue. More often than not, hub problems appear on Macintosh.... it seems Apple assumes hardware meets specs, but Windows and Linux are designed to try to accommodate poorly designed hardware. Teensy reboots and does a number of things quickly. To your PC (or whatever hub it's plugged into), Teensy electrically disconnects and reconnects, as if the cable were physically unplugged for a brief moment. Teensy uses timings that are within the USB spec, which all USB hubs are supposed to be designed to meet. But some poorly designed hubs don't meet the USB spec, and one place poorly designed hardware is not tested well is short device disconnect times (especially if they only tested by physically plugging cables).

I know this must sound pretty suspicious, if all your other USB stuff is working, but it's very likely some piece of your USB communication system is not working well.
 
First, do not go down the terrible path of fiddling with Windows drivers!

You do NOT need any special driver for Teensy to be able to program. In its Serial modes, you do need a driver to use the Arduino Serial Monitor. But you don't need that to simply program code like the LED blink. All the programming uses HID, not Serial, and every version of Windows has HID drivers built in. So don't worry about drivers until you can successfully get Teensy programmed with the LED blink example! Fiddling with drivers is a huge distraction.



Well, thankfully Windows 8.1 is at least telling you "Device Descriptor Request Failed". That's *far* better than earlier versions of Windows!

Teensy absolutely does work with Windows 8.1. Many people have used it with 8.1, and I have personally tested on 8.1. I also started testing on Windows 10 today. It definitely does work, so this isn't a problem specific to Windows 8.1.

There's 2 possible causes for this sort of problem.

#1 - As just mentioned, if code is crashing the processor as Windows tries to read the USB descriptors, this is exactly what you'd expect. But if you've never managed to program anything onto your Teensy, it should still have the LED blink we load onto it while testing. And regardless of what bad code has been loaded, after you press the button, it will run the bootloader, which appears as a USB HID device.

#2 - Bad USB cables, hubs or other hardware can cause communication errors. My guess is you've got something like that in play here. That screenshot shows 2 hubs and a special USB host controller.

The most common cable problem is charge-only cables for phones, which don't have any data wires.... but whatever you're using must have data lines, since a bad device is showing up, but failing to properly communicate.

Flaky USB hubs are also sometimes an issue. More often than not, hub problems appear on Macintosh.... it seems Apple assumes hardware meets specs, but Windows and Linux are designed to try to accommodate poorly designed hardware. Teensy reboots and does a number of things quickly. To your PC (or whatever hub it's plugged into), Teensy electrically disconnects and reconnects, as if the cable were physically unplugged for a brief moment. Teensy uses timings that are within the USB spec, which all USB hubs are supposed to be designed to meet. But some poorly designed hubs don't meet the USB spec, and one place poorly designed hardware is not tested well is short device disconnect times (especially if they only tested by physically plugging cables).

I know this must sound pretty suspicious, if all your other USB stuff is working, but it's very likely some piece of your USB communication system is not working well.


Thank you, Paul, for your reply. One detail I love about Teensy 3.1 plus many other details , is getting support from the creator of Teensy. Make me feel that I am not abandoned on my own.
Anyway, problem is solved, also it was my fault somehow, I kept looking or selecting a serial port in the Arduino IDE, Teensy does not need that. Am I right here? I think I am because Teensy is a happy camper now. I need to look a little more into the HUB, its a USB 3 compliant HUB, but I think something is going on here.

I ruled out the cable issue right from the beginning because is a cable I use to program my HP Prime Calculator, it was me :confused: I was not clear on this.

What details I like about Teensy? Among many, The RAM! Some times I create projects that even the Mega2560 runs out of RAM, Teensy will take care of that.
 
... I kept looking or selecting a serial port in the Arduino IDE, Teensy does not need that. Am I right here?

Correct. Teensy uses HID protocol for programming, not serial.

Some times I create projects that even the Mega2560 runs out of RAM, Teensy will take care of that.

Yeah, going from 8K to 64K RAM is a big step up. :)
 
@Andreas,

Thanks for the reset suggestion. My teensy 3.1 was also "dead" on the USB bus, connecting reset to GND while inserting the USB cable brought it back to life.

Thanks, Regards, Otto
 
hello..
my teensy3.2 was working perfectly till yesterday...
today while flashing code something got struck and now its dead, my device manager does not recognize any Device / hardware change.
I've tried by connecting reset (pin 34) to ground while connecting USB to PC. but still its not recognizing..

PLEASE HELP..
 
Teensy tends to do that. Out of the blue, it loses its mind. One way I am able to bring it back to life is by running the "blink" sketch. Try it.
 
Teensy tends to do that. Out of the blue, it loses its mind. One way I am able to bring it back to life is by running the "blink" sketch. Try it.
 
hello..
my teensy3.2 was working perfectly till yesterday...
today while flashing code something got struck and now its dead, my device manager does not recognize any Device / hardware change.
I've tried by connecting reset (pin 34) to ground while connecting USB to PC. but still its not recognizing..

PLEASE HELP..

I missed this come in - I've been seeing similar behavior recently on Windows 10 and the IDE 1.6.6. - Though I have never tried a 'reset' pin yet.

Normally these steps work: https://forum.pjrc.com/threads/31518-Can-t-communicate-with-Teensy-3-2-through-Teensyduino?p=88073&viewfull=1#post88073

If those steps don't work restarting Windows - Teensy ujnplugged - should clear it up - then do the push button connect after the IDE loads and verifies the sketch.

Recently trying to suffer through the IDE SerialMontor - that goes away and needs restarted on each Verify - I could not get the Teensy back at all. Program button would take the Teensy offline and the TeensyLoader would never find it - and it wasn't in DevMan.

If I plugged in a second Teensy with the same display ready to run the same code I found it would work and then I could go back to the first unit. I think Windows gets confused still seeing the port come and go and then doesn't bother with it for 'some time' - or until some action like a second unique ID Teensy shows up and clears the way.

I have the Touch ILI9341 socketed to a Teensy board and I wonder sometimes if picking it up the display shifts giving off power surges or something - but something causes it.

Also even with just a single Teensy powered the IDE Upload rarely finds the Teensy on Win 10 - I have to push the button - or use TYQT!
 
Last edited:
Same problem with LC

This is biting me on a Teensy LC right now. (Ubuntu 14.04) I can compile, I get the message
"did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch."
but it doesn't load and after that attempt lsusb does not show the Teensyduino device.

If I press the reset button on Teensy and immediately do lsusb after a two seconds lsusb does show the device. But after the apparent load the device is missing again.

I observe though that if I put a delay(1000) right after Serial.begin(9600); loading is successful after a reset button press.

Here is dmesage from one a fail with no delay:

Code:
[ 9343.188057] cdc_acm 3-3:1.0: ttyACM0: USB ACM device
[ 9827.425882] usb 3-3: USB disconnect, device number 50
[ 9828.124021] usb 3-3: new full-speed USB device number 51 using ohci-pci
[ 9828.333947] usb 3-3: New USB device found, idVendor=16c0, idProduct=0478
[ 9828.333955] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 9828.333959] usb 3-3: SerialNumber: 0001B010
[ 9833.338829] hid-generic 0003:16C0:0478.003E: hidraw2: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:02.1-3/input0
[ 9834.138555] usb 3-3: USB disconnect, device number 51
[ 9834.932022] usb 3-3: new full-speed USB device number 52 using ohci-pci
[ 9835.156941] usb 3-3: New USB device found, idVendor=16c0, idProduct=0483
[ 9835.156948] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9835.156952] usb 3-3: Product: USB Serial
[ 9835.156955] usb 3-3: Manufacturer: Teensyduino
[ 9835.156957] usb 3-3: SerialNumber: 1106080
[ 9835.159983] cdc_acm 3-3:1.0: This device cannot do calls on its own. It is not a modem.
[ 9835.160040] cdc_acm 3-3:1.0: ttyACM0: USB ACM device
[ 9888.753969] usb 3-3: USB disconnect, device number 52
[ 9889.304030] usb 3-3: new full-speed USB device number 53 using ohci-pci
[ 9889.513953] usb 3-3: New USB device found, idVendor=16c0, idProduct=0478
[ 9889.513961] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 9889.513964] usb 3-3: SerialNumber: 0001B010
[ 9894.518851] hid-generic 0003:16C0:0478.003F: hidraw2: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:02.1-3/input0
[ 9895.614710] usb 3-3: USB disconnect, device number 53
[ 9896.408021] usb 3-3: new full-speed USB device number 54 using ohci-pci
[ 9901.588026] usb 3-3: device descriptor read/64, error -62
[ 9901.876019] usb 3-3: device descriptor read/64, error -62
[ 9902.156019] usb 3-3: new full-speed USB device number 55 using ohci-pci
[ 9902.336022] usb 3-3: device descriptor read/64, error -62
[ 9902.620023] usb 3-3: device descriptor read/64, error -62
[ 9902.900027] usb 3-3: new full-speed USB device number 56 using ohci-pci
[ 9903.308064] usb 3-3: device not accepting address 56, error -62
[ 9903.484034] usb 3-3: new full-speed USB device number 57 using ohci-pci
[ 9903.892026] usb 3-3: device not accepting address 57, error -62
[ 9903.892067] hub 3-0:1.0: unable to enumerate USB device on port 3
jbh@jbh-A7N8X-X:~$

This is dmesg with 1 second delay added:

Code:
[10515.524033] usb 3-3: new full-speed USB device number 94 using ohci-pci
[10515.733941] usb 3-3: New USB device found, idVendor=16c0, idProduct=0478
[10515.733949] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[10515.733952] usb 3-3: SerialNumber: 0001B010
[10520.739854] hid-generic 0003:16C0:0478.0043: hidraw2: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:02.1-3/input0
[10521.721469] usb 3-3: USB disconnect, device number 94
[10522.516021] usb 3-3: new full-speed USB device number 95 using ohci-pci
[10522.740942] usb 3-3: New USB device found, idVendor=16c0, idProduct=0483
[10522.740950] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10522.740953] usb 3-3: Product: USB Serial
[10522.740956] usb 3-3: Manufacturer: Teensyduino
[10522.740959] usb 3-3: SerialNumber: 1106080
[10522.744034] cdc_acm 3-3:1.0: This device cannot do calls on its own. It is not a modem.
[10522.744066] cdc_acm 3-3:1.0: ttyACM0: USB ACM device
 
Status
Not open for further replies.
Back
Top