Teensy 3.5 no port

Status
Not open for further replies.
I've been over and over and over with this... Teensy 3.5 will work for a while, and then it won't recognize a USB/Serial port to program anything (inside the Arduino IDE). It just randomly works, and then it doesn't. It's getting power and all, and it still works with the sketch I had previously installed (It connects to a BLE break-out/iOS app I'm developing, everything soldered to a PCB... But even before the PCB when I had the Teensy on a breadboard I had the same issues), I can't program anything (blink, etc) without a port.

I have tried deleting all Arduino & Teensyduino files and re-installing. Nothing seems to work. I've tried various versions of the Arduino IDE also. I'm on OSX 10.13.6

This is probably the 5th time this has happened...It just seems to "fix itself" every once and a while and then stops working again. Any help would be appreciated.
 

Attachments

  • Screen Shot 2018-12-09 at 1.32.06 AM.png
    Screen Shot 2018-12-09 at 1.32.06 AM.png
    206.6 KB · Views: 121
Does it work to upload with push of Program button?
With TeensyLoader open the Help / Verbose info to see what it shows for devices.

No idea other than BLE device usage or code provided, perhaps it is faulting the processor for failed memory access or other coding/hardware problem? Perhaps this will show if that is the case: debug_t3 library zip is posted there - not a real thread yet - but posts in that thread should show its use.
 
The program button does nothing...The BLE isn't the problem, It's always worked with the Teensy & still does. But I can't get the Teensy to find a port to program a new sketch.
 

Attachments

  • Screen Shot 2018-12-09 at 2.03.46 AM.jpg
    Screen Shot 2018-12-09 at 2.03.46 AM.jpg
    108.6 KB · Views: 109
This is the Verbose Mode text when I try to upload the Blink sketch:

02:12:52.168 (post_compile 5): Begin, version=1.44
02:12:52.168 (loader): remote connection 18 opened
02:12:52.170 (post_compile 5): Sending command: comment: Teensyduino 1.44 - MACOSX (teensy_post_compile)
02:12:52.175 (loader): remote cmd from 18: "comment: Teensyduino 1.44 - MACOSX (teensy_post_compile)"
02:12:52.177 (loader): remote cmd from 18: "status"
02:12:52.178 (post_compile 5): Status: 0, 1, 0, 0, 0, 0, /var/folders/zq/0zn355w976j3r3d10nwxtkgm0000gn/T/arduino_build_51160/, Blink.ino.hex
02:12:52.178 (post_compile 5): Sending command: dir:/var/folders/zq/0zn355w976j3r3d10nwxtkgm0000gn/T/arduino_build_575537/
02:12:52.178 (loader): remote cmd from 18: "dir:/var/folders/zq/0zn355w976j3r3d10nwxtkgm0000gn/T/arduino_build_575537/"
02:12:52.179 (post_compile 5): Sending command: file:Blink.ino.hex
02:12:52.179 (loader): remote cmd from 18: "file:Blink.ino.hex"
02:12:52.182 (loader): File "Blink.ino.hex". 10356 bytes, 2% used
02:12:52.185 (loader): remote cmd from 18: "status"
02:12:52.186 (post_compile 5): Status: 1, 1, 0, 0, 0, 0, /var/folders/zq/0zn355w976j3r3d10nwxtkgm0000gn/T/arduino_build_575537/, Blink.ino.hex
02:12:52.186 (post_compile 5): Disconnect
02:12:52.815 (loader): remote connection 18 closed
02:12:57.268 (post_compile 6): Begin, version=1.44
02:12:57.269 (loader): remote connection 18 opened
02:12:57.270 (post_compile 6): Sending command: comment: Teensyduino 1.44 - MACOSX (teensy_post_compile)
02:12:57.274 (loader): remote cmd from 18: "comment: Teensyduino 1.44 - MACOSX (teensy_post_compile)"
02:12:57.280 (loader): remote cmd from 18: "status"
02:12:57.281 (loader): file changed
02:12:57.284 (loader): File "Blink.ino.hex". 10356 bytes, 2% used
02:12:57.286 (post_compile 6): Status: 1, 1, 0, 0, 0, 0, /var/folders/zq/0zn355w976j3r3d10nwxtkgm0000gn/T/arduino_build_575537/, Blink.ino.hex
02:12:57.286 (post_compile 6): Disconnect
02:12:57.316 (loader): remote connection 18 closed
 
Interesting - I don't do MAC - may be an issue there. Was there a button push during that verbose output collection?

Let me know if you get the debug_t3 hooked up - or get stuck trying. Just saving the zip content to sketchbook\libraries and adding:[ #include "debug_t3.h" ] will show on SerMon if the CPU is faulting. Though Button should fix that unless PC is taking the USB wholly offline in some fashion where it doesn't see it come up as HID
 
Not showing up at all in the "Teensy Ports" menu is usually caused by a bad USB cable or other USB hardware issue.

The error in msg #6 is a programming mistake (unrelated to USB, hardware, port detection), maybe something wrong in that library?
 
No button push during the verbose mode output. I get an error with the debug_t3 #include View attachment 15328

My bad it seems on the zip file not including the code below for missing file:: ...libraries\debug_t3\debugdump.cpp

A quicker fix would be to put this in your sketch:
Code:
/ For haltif() entering 'd' calls this optional code
// It can call functions or dump globals.
void Debug_Dump(void)
{
  DebSer.print(" User Custom Debug Dump. Micros==");
  DebSer.println(micros());
  // Put code here to call after Fault or HaltIf() - or call it in sketch
  return;
}


CODE for missing file:: ...libraries\debug_t3\debugdump.cpp
Code:
#include <Arduino.h>  // types and class define

#ifdef __cplusplus
extern "C" {
#endif
extern Stream &DebSer; // Default USB
#ifdef __cplusplus
} // extern "C"
#endif

__attribute__((weak)) 
void Debug_Dump(void)
{
  DebSer.print(" User Debug Dump default. Micros==");
  DebSer.println(micros());
  return;
}
 
Not showing up at all in the "Teensy Ports" menu is usually caused by a bad USB cable or other USB hardware issue.

I've tried multiple USB cables, all of which work with all of my other arduino boards (UNO, mega, Teensy 3.2, and a Mini-Rambo I use to run an MPCNC machine). I get a serial port with all of those boards, never had a problem with the cables before
 
You keep saying "serial port", so I want to be clear that Teensy sometimes uses serial or other protocols, other times uses HID protocol. We get this misunderstanding pretty often from people who are very used to Arduino's model of "everything is a serial port".

Not everything is serial. Most of Arduino's boards have a dedicated USB-serial chip, so they are always the same serial port. Knowledge & experience with that sort of hardware does not always apply to native USB boards, where the USB changes.

Teensy uses HID, not serial, when in programming mode. This is important to understand for troubleshooting.

Here's a screenshot from my Macbook Air, to show you the best way to troubleshoot.

sc.jpg

There are two important points in this screenshot.

#1 - Turn off the "Auto" mode in Teensy Loader. By default Arduino turns it on, so Teensy will reprogram and reboot with your freshly compiled code as quickly as possible. For troubleshooting, you want to turn Auto mode off, so you can see whether Teensy Loader detects the hardware.

#2 - In the Ports menu, Teensy appears as "HID=16c0:0478" when it's in programming mode. It is *NOT* a serial device. This is normal, because Teensy uses HID protocol in this mode. If your Teensy and Mac and USB cable are working properly, you should always be able to get Teensy into this mode by pressing the button. Normally when Auto is turned on, this mode lasts for only a second or two. With Auto turned off, you can easily observe whether Teensy is working properly and your Mac is able to detect it.

In all other modes, the USB communication on Teensy depends on the code you've loaded into its memory. This is different from boards like Arduino Uno which have a dedicated USB chip. On those boards, no matter what your program does, you can't mess up the separate USB-serial chip. On Teensy, the USB is running in the same chip and is controlled by the code you've loaded. That's why you can do stuff like the Tools > USB Type menu, which is obviously impossible on boards like Uno which only work as serial. But it also means plenty can go wrong, because the USB is on the same chip as your program.

So please, for the sake of troubleshooting, turn off Auto mode and press the button, then look for the HID interface (not serial). This mode runs only the bootloader from PJRC and does not depend on any code you've put onto Teensy's memory. Troubleshoot first with this mode, so you're running with a known-good setup code-wise, while trying to figure out if something is wrong with the hardware or on your Mac.
 
Sorry for the confusion on my end...I got that HID option to show up once a few weeks ago when this wasn't working the last time. Same cable, the board never got unplugged from my macbook while I was trying to troubleshoot, and the HID option only showed up after I deleted and reinstalled the IDE & Teensy loader. I've tried that trick again a few times now, nada

I tried the troubleshooting suggestion you made about the auto mode. Still nothing

On my PCBs that use Teensy I always include the option for a USB-B Male port, and jump to it by soldering wires to the pads on the bottom of the Teensy (see the Eagle CAD portion of my screenshot). I do this because I have several clients that hate those micro-USB ports (I guess they're clumsy and have broken them in the past when plugging/un-plugging the cable). In this case, the larger USB-B port wasn't needed, so I didn't bother jumping the D- D+ pads before I soldered the Teensy to the PCB.

However, I just tried soldering on the USB-B port anyway, and jumped some wires from the D- D+ through-holes on the top of the board since I no longer have access to the bottom. Tried several USB cables with that as well, no HID port.

The teensy is definitely getting power & ground, as it is powering the adafruit BLE on the PCB and my iOS app can communicate with it. Something's going on with the USB data in/out here? Like I mentioned before, I've been having this problem with this board even when it was just on my breadboard.
 

Attachments

  • teensy35.jpg
    teensy35.jpg
    138.7 KB · Views: 117
The indicated D+ and D- pins are the secondary HOST USB signals for T_3.6. They are not the Primary Serial USB pads that program the Teensy. Those are the WIDE pads directly under the USB connector shown in post #11 image. On T_3.5 those indicated pins are Analog pins A25 and A26.
 
Thanks for the "pop it out of auto trick". I was in the same boat this AM and that "fixed" it.

-jim lee
 
FWIW, on the next Teensy we're adding a red LED which will be dedicated to the bootloader, to show status of what it's actually doing. I'm still working on the details, but there will definitely be a dim blink to show when the bootloader is sitting waiting for the PC to do USB enumeration.
 
A new teensy? Small size is good. I love the 3.2s. I'd really love a whopping upsize in RAM though!

Since you have one on the drawing board as it were..

P.S. Thanks for making these things.

-jim lee
 
A new teensy? Small size is good. I love the 3.2s. I'd really love a whopping upsize in RAM though!

Since you have one on the drawing board as it were..

P.S. Thanks for making these things.

-jim lee

Yes T_4 … see this thread :: Teensy-4-0-(hypothetical)-pin-assignments

T_3.2 sized PCB w/600 MHz MCU with 1 MB RAM and 4 GB Flash … and 'a red LED which will be dedicated to the bootloader' (indeed 'red Fault' announce feature would be nice too)
 
I've been searching google and this forum for the last 5 hours and have tried everything people have offered up. This thread seems to be closest to my issue. The Teensy 3.5 I'm using does not show up in the HID listing as shown in post 10.

I had been testing my setup outside for two days; 50-60F day, 30F at night. It was in a weatherproof box during this time. I brought it in when it was about to start raining as I'm preparing to add functionality to the system and it stopped working after I opened the container. It might have been a condensation issue that caused this. There were not large water droplets...not even tiny ones as far as I could tell...but wanted to set the stage where this circuitry has been working.

The Teensy 3.5 that I've been using for 3 weeks now has been inside, it only went outside for test a few days ago, and it seems to have died on me. It does not connect to Teensyduino software as far as I can tell and does not show up as a HID device in the port listing as seen in post #10. It is not running the program I had loaded on it, nor will it accept the blink program. There is 3.3V on the 3.3V pin, the Program and Reset lines pull low when I press the button, but seems no communication to the computer.

I'm using Arduino interface on a Mac, all fresh installs since it stopped working. The Verbose window does not show anything when I press the button on the 3.5...should it? I've never looked at the window when it was working, so don't know what to expect.

The circuitry is powered from a USB battery at 5V and is regularly plugged into a USB cable to program the system. I've seen that's a no-no on here, but the pictures for cutting traces are not for the 3.5. Do I need to cut a trace since it's powered both ways when I'm programming it? How have I possibly damaged the board by doing this? I do understand electronics if you can offer up a detailed explanation.

I am monitoring a voltage from a USB battery pack that is going directly to the A1 pin. The battery pack was very low and had probably shut it's self off, but the cell voltage was still on the pin. Could the device be damaged if there is voltage applied to an analog pin without rail voltage?

Are there any other troubleshooting ideas I should try?

Thank you!
 
Alot of times this is due to faulty usb cables or power only usb cables, even if they worked before, or even if you changed the cable, change it again. The trace is on all teensy 3.x boards, you should only provide power from 1 source, not both

One user had to change usb cables 3 times before it worked, as his first 2 were not good..
 
Typically a Teensy Card with the T_3.5 on the back side, or look at the web images it shows the trace to cut when the Teensy is powered externally and USB connection is desired - as noted on all T_3.x and T_LC information cards.

Not sure if that could be affecting the USB port with feedback voltage. But as tonton81 notes - try a known good cable - good cables go bad - I know.

I just did this BING search pjrc forum 'good cables can go bad'
and first in list is a post to that effect :: Teensy Fails to Upload or to Blink or run, Wonder if it got bricked? - though it is the odd print link ...
 
Have you checked the Teensy output voltages - there are 'Troubleshooting' posts somewhere about that given it may be physically/electrically unhealthy?

The first would be seeing 3.3V on those pins when proper VIN is applied - it seems there is at least one more check perhaps involving PGM or RESET.

No backup Teensy to test with?
 
The 3.3v output next to the analog ground is functioning, but have only probed reset and program pins to check state change during a button press(both go low as expected).

I’m wondering if there may be a cold solder joint somwwhere that experienced thermal stress during the cold to warm cycle of working outside and then bringing inside. I’ll lightly push on some components while testing...I was running out of ideas at 2am. 😅

I was using a Arduino Mini Pro prior to the teensy and ran out of RAM in my project due to three large lookup tables and the associated variables. I have three Mini Pros, but no other Teensy boards. I was hoping to not have to buy another for this project, but it’s only an amazon click away.
 
Thank you for everyone's help!

When I click program in Arduino IDE, I see the verbose output in Teesnyduino:

14:42:51.101 (loader): file changed
14:42:51.113 (loader): File "Teensy_PWM_white_LED_RTC_V1_FUNCTIONAL.ino.hex". 41828 bytes, 8% used
14:42:51.239 (post_compile 29): Begin, version=1.45
14:42:51.240 (loader): remote connection 13 opened
14:42:51.245 (post_compile 29): Sending command: comment: Teensyduino 1.45 - MACOSX (teensy_post_compile)
14:42:51.251 (loader): remote cmd from 13: "comment: Teensyduino 1.45 - MACOSX (teensy_post_compile)"
14:42:51.254 (loader): remote cmd from 13: "status"
14:42:51.257 (post_compile 29): Status: 1, 1, 0, 0, 0, 0, /var/folders/5m/_mwb08456bn5nr_w8c8gv2100000gn/T/arduino_build_230920/, Teensy_PWM_white_LED_RTC_V1_FUNCTIONAL.ino.hex
14:42:51.257 (post_compile 29): Disconnect
14:42:51.289 (post_compile 30): Begin, version=1.45
14:42:51.340 (loader): remote connection 14 opened
14:42:51.343 (post_compile 30): Sending command: comment: Teensyduino 1.45 - MACOSX (teensy_post_compile)
14:42:51.350 (loader): remote connection 13 closed
14:42:51.358 (loader): remote cmd from 14: "comment: Teensyduino 1.45 - MACOSX (teensy_post_compile)"
14:42:51.369 (loader): remote cmd from 14: "status"
14:42:51.372 (post_compile 30): Status: 1, 1, 0, 0, 0, 0, /var/folders/5m/_mwb08456bn5nr_w8c8gv2100000gn/T/arduino_build_230920/, Teensy_PWM_white_LED_RTC_V1_FUNCTIONAL.ino.hex
14:42:51.372 (post_compile 30): Disconnect
14:42:51.384 (post_compile 31): Running teensy_reboot: /Applications/Arduino.app/Contents/Java/hardware/teensy/../tools/teensy_reboot
14:42:51.452 (loader): remote connection 13 opened
14:42:51.458 (reboot 32): Begin, version=1.45
14:42:51.458 (reboot 32): location = /dev/cu.Bluetooth-Incoming-Port
14:42:51.458 (reboot 32): portprotocol = serial
14:42:51.458 (reboot 32): portlabel = /dev/cu.Bluetooth-Incoming-Port
14:42:51.458 (reboot 32): Serial device /dev/cu.Bluetooth-Incoming-Port will be tried first
14:42:51.458 (reboot 32): USB device add callback
14:42:51.509 (loader): remote connection 13 closed
14:42:51.519 (loader): remote connection 13 opened
14:42:51.521 (reboot 32): USB device remove callback
14:42:51.522 (reboot 32): Serial add callback
14:42:51.532 (reboot 32): Serial remove callback
14:42:51.535 (reboot 32): HID Manager started
14:42:51.536 (reboot 32): Disconnect
14:42:51.611 (loader): remote connection 13 closed
14:42:51.628 (loader): remote connection 14 closed

Screen Shot 2019-01-13 at 2.46.29 PM.jpg

Also, here's a pic of the breadboard. everything has been disconnected except for a couple of pull up resistors to SCL0 and SDA0 lines in hopes that something was pulling down the circuitry. No such luck. This 3.3V line as well as the one mentioned in the previous post are both functional.

IMG_9012_compressed.jpg
 
Status
Not open for further replies.
Back
Top