did I brick my teensy3? usb connects, then disconnects almost right away

Status
Not open for further replies.
S

skidd

Member
I'm wondering.. did I somehow manage to kill my Teensy3.2?

I've been working with this thing for a few months now.. with good success. I'm making a POV clock with 32 APA102 leds (DotStars).
I'm using PlatformIO and VisualStudioCode on a Linux machine.

Full Disclosure. My code is setup to clock the cpu at 120Mhz, and it's been working fine for pretty much the whole time.
I did try 144 and 168, but found it to be somewhat unstable.. so.. backed down to 120 and left it there.
I have the spi pins to the leds direct. no 3.3->5v level shifter. They have been working fine without it.

The other day, the USB port stopped responding. Nothing I did could get it to show back up on my machine. Plus, none of the on-board code would run. I tried multiple times to load up the good-old "blink" example using the arduino IDE with the CPU set to 72Mhz.
I'd hit "upload". the teensy dialog box would appear.. but nothing happened. I'd try hitting the flash button on the teensy.. but nothing. Unplug the USB, hold the flash button.. plug it in.. nothing. I have a coin cell batter wired in and a crystal to keep the RTC active. I pulled that battery out just in case. Still nothing. the dmesg log shows no activity at all. Not even a "usb detected.. error error error" of any kind. Nothing at all. So.. I just walked away for the day, fed up.

Came back the next day to try again. Plugged it in.. and the HID device showed in my dmesg log this time. Flashed "Blink" and the onboard LED started flashing like nothing was ever wrong.
Re-flashed blink a few more times .. just to see it upload.. and it worked as expected. Somehow it was back from the dead.

Went over to VSCode and uploaded my main program.. and it worked fine. Fired up the clock, and it was doing it's thing. :) No idea why.. but.. waiting a long time somehow restored it. So.. I continued to work on the code.

After about.. oh.. a couple of hours of changes and uploads.. it stopped working again. Same thing.. nothing in the dmesg log. Prior to it not responding though.. there were a long list of repeated messages in dmesg..
Code: 
xhci_hcd 0000:00:14:0: WARN Cannot submit Set TR Deq Ptr
xhci_hcd 0000:00:14:0: A Set TR Deq Ptr  command is pending.

I left it unplugged for about 15 minutes to see if a "wait" would bring it back. and it didn't. I have a 12v -> 5v power regulator wired in. I wondered if it's output cap was holding enough charge? Seemed a stretch, but I disconnected the regulator. Still nothign comes back. No USB activity in the dmesg log.

Again.. fed up, I walked away until later that night.

Once again.. I was able to plug in the USB, and flash "blink" onto the teensy.
This is getting silly now.

This time, I leave blink on it, and just leave it plugged into the USB. Watched the LED flash for about 30 seconds.. then it just stopped.
dmesg showed:

Code: 
[79390.151627] usb 3-4.3.1: new full-speed USB device number 31 using xhci_hcd
[79390.268611] usb 3-4.3.1: New USB device found, idVendor=16c0, idProduct=0486
[79390.268617] usb 3-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[79390.268619] usb 3-4.3.1: Product: Teensyduino RawHID
[79390.268621] usb 3-4.3.1: Manufacturer: Teensyduino
[79390.268623] usb 3-4.3.1: SerialNumber: 4797740
[79390.270121] hid-generic 0003:16C0:0486.0016: hiddev0,hidraw0: USB HID v1.11 Device [Teensyduino Teensyduino RawHID] on usb-0000:00:14.0-4.3.1/input0
[79390.270771] hid-generic 0003:16C0:0486.0017: hidraw1: USB HID v1.11 Device [Teensyduino Teensyduino RawHID] on usb-0000:00:14.0-4.3.1/input1
[79390.680573] usb 3-4.3.1: USB disconnect, device number 31

Even thought it was still connected.
I unplugged, and re-plugged. .. the LED flashed about 5 or 6 times, and stopped. Same thing.
did it again.. got about 2 led flashes.
Again.. .. and now nothing. No more USB events in dmesg, and no flashing onboard LED.

I have a spare teensy3.2 not wired to anything at all. If I upload blink, or my POV code, it loads and runs without a problem. (not surprised by this to be honest). Both blink and my code sat on it running fine for about 30 minutes without a hicup.

I am planning to try to de-solder the parts wires wires to see if one of the connections is the blame, but given it had been running fine for a long time, I seems unlikely it's one of them. but.. who knows. I'll update in here with the result of desoldering.

Any thoughts? Why the USB connected just got progressively worse and worse until nothing.
Do I just chalk this thing up to the Gods of Blue-Smoke Electronics and use my backup teensy? I just hate the idea I might burn it up and still have no idea how I did it.
 
Update:

I won't lie, desoldering the teensy was not something I was looking forward to doing.. but. I had no choice, it wasn't working.
Yeah.. I soldered directly to where it's installed instead of headers due to weight and space issues. I'm targeting over 1000rpm on this POV clock.
Anyway..
Desoldered it, plugged in the USB.. "blink" fired up.. lasted about.. oh.. 20 seconds.. and stopped. No usb activity.
As far as I'm concerned... what ever I've done.. it's hurt. So.. I soldered in the spare Teensy, installed my software.. and everything is up and running again.

then.. yeah.. then...

I desoldered the last component still attached to teh old teensy. It's just a 3 pin IR receiver. I only have 2 left in my parts drawer, so I wanted to save this one.
As I desoldered and pull it from the teensy holes... A single tiny strand of lose wire showed it self.
No way.. it couldn't have been that somehow?....
Plugged the now totally bare Teensy into a USB cable.. and "blink" has been running perfectly for 10 minutes.
Was it the tiny strand of wire? Or.. a failed IR receiver that was shorting out internally? I'll never know. My money is on the IR receiver that is now in the trash.

I have to be honest... if this proves to be the actual reason for the issues (going to leave it blinking all day).. I'll be very happy. I can grasp with a "short" being the problem. Trying to figure out what in my software was the problem was keeping me up at night.
 
Looks like you chased it down, but wild guessing on sequence of events is that 'something' around that IR device was drawing power above the continuous supply limit of the onboard 3.3V regulator but not a true short circuit. As it it heated up the regulator did what it is designed to do and throttled the output voltage until the temperature fell, placing the Teensy in reset and breaking USB coms. Unplugging it would allow the regulator to cool down and run normally but anything that did not leave a time delay for cooling wouldn't work.

Of interest would have been the 5V and 3.3V voltages while in the failed condition and also what a scope showed on both of them. If working with lots of LEDs watch for similar problems that show up only when you have a high intensity pattern active leading you to think the pattern code is faulty where in fact the problem is high current draw impacting things upstream.
 
Might have been pretty interesting to try put my scope on the 5v and 3.3v rails.. since it's all spinning at almost 1000 RPM.

It's funny you mention chasing pattern issues in the logic, when it's the power causing faults....
I think that's the next "bug" on my list. I was having very random times when the image would just get all garbled and I'd have to reboot it.
It only seemed to happen when a lot of the LEDs were firing for the entire rotation. Screens I had designed that only a handful of LEDs fired almost never seemed to crash.
But, on one of the images that would crash the display almost every time, I tried lowering the color brightness. Now, it seems to have totally stopped crashing. So.. something to do with too much power to the LEDs is still having a negative impact. My bench power supply feeding 12v jumps up an additional 350mA when the "bright" screen comes on that causes the random glitches. I wonder if it's actually related to my not having a 3.3->5v level shifter on the SPI pins? Or if I need a better vreg than the bulk 2596 I'm using.

For reference, I'm feeding 12v@4a up through a custom slip ring. Then, a LM2596 dropping to 5v (supposed to be good for 3A) and feeding the VIN on the teensy as well as the 5v power on the LED strip. So, the Teensys onboard vreg should not be getting taxed by this setup.
 
Another Update..solved the random garbled image issue too.
Turned out to be noise on my hall effect sensor. the internal teensy pull-up wasn't up to the task (I think I read it's a 33k). a 6.8K external pullup however is up to the task.
That.. and something unexpected. my interrupt handler was being triggered on both "rising" and "falling" edges for some reason. No matter what I put in the "attachInterrupt" call, it always called on both edges.
Truth be told, I was hoping that "CHANGE" would have given me a chance to track the timing of both sides of the magnetic field, but nothing I did would make that happen. I was a bit surprised by this.
In the end, I have the ISR watching for "RISING", and I had to add a "if digital pin is HIGH" inside my ISR to keep the falling edge from causing false triggers.
 
Status
Not open for further replies.
Back
Top