PDA

View Full Version : Teensyduino 1.26 Beta #1 Available



Paul
10-22-2015, 05:22 PM
Here is a first beta test for Teensyduino 1.26.

The main changes are fixes for Macintosh. USB Serial is fixed for El Capitan.

The installer and Teensy Loader should now work if you have Security & Privacy configured to only allow applications from the mac store and identified developers (which is the default setting). However, you *must* run Arduino at least once before the Teensyduino installer modifies it.


Edit: old beta test linkes removed. Full non-beta release is here:
http://www.pjrc.com/teensy/td_download.html



Here's a complete list of the changes since 1.25:



Fix USB Serial on Macintosh 10.11 El Capitan
Partially fix Mac signatures (still must run Arduino once before installing)
AnalogWriteFrequency supports extremely low speeds (thanks Theremingenieur)
Improve tone() changing frequency while running
Update libraries: AltSoftSerial, FastLED, ILI9341_t3
Add XPT2046_Touchscreen library
Improve Ethernet library W5200 reset handling
Update SD library examples
Add I2S 2-port register bitfield names
Initial work on MTP Disk (incomplete)

Theremingenieur
10-23-2015, 07:51 AM
Install and quick compile test went without problems (Mac OS X 10.11.1 El Capitan).

Thank you for mentioning my tiny contribution to analogWriteFrequency(), but I'd prefer to be mentioned with my forum pseudo (Theremingenieur), rather than with the github name (universpharmacie). That github account belongs to my day job's employer and I had to use it for the pull request since the github GUI tool for OS X is not capable to handle more than one single account...

If I find a few minutes during the upcoming weekend, I will still write a little about the extended functionality, so that the table on the website which relates analogWrite frequencies and resolution can be extended.

Paul
10-23-2015, 10:26 AM
I've updated the list of changes.

Theremingenieur
10-23-2015, 12:58 PM
Thank you, Paul! :)

defragster
10-24-2015, 12:22 AM
Posting Beta note on web? :: http://www.pjrc.com/teensy/td_download.html

defragster
10-24-2015, 08:28 AM
Installing 1.26b1 on 2nd Win10 machine - both okay - but the second I closed the IDE's and left Teensy open - then after all the clicks to get there is just aborts - would be nice if it detected open Teensy Loader up front and said to close before it got all fatal like - or if it gave a back button to retry.

esapode688
10-25-2015, 02:47 PM
Thank you Paul !!!! :D Its all working !

mjhilger
10-26-2015, 03:04 PM
I know I'm behind the curve, but what version of Arduino IDE will the new software work with?

PaulStoffregen
10-26-2015, 03:13 PM
I know I'm behind the curve, but what version of Arduino IDE will the new software work with?

1.0.6, 1.6.1, 1.6.3 and 1.6.5.

Every installer always shows a list of the Arduino versions it knows. Admittedly, that info is hidden in the middle of the intro page nobody reads.... but it's always there if you know where to look.

PaulStoffregen
10-26-2015, 03:24 PM
Support was dropped for Arduino 1.6.0, 1.6.2 and 1.6.4, because those versions had serious bugs.

1.6.0 and 1.6.2 were quickly replaced by 1.6.1 and 1.6.3, because the bugs were so serious.

1.6.4 was available for quite some time, but it had a really unpleasant bug where libraries using templates and other advanced C++ features wouldn't compile. FastLED was one of the popular libraries impacted.

Massel
10-27-2015, 03:54 PM
HELP!!

My mac can't even see any Teensy 3.1 on USB since El Capitan update on friday to 10.11.1.
I have a important test goning on in 1 our with some prototypes buld up with the Teensy and I can't load anything on the Teensy right now!!!

PaulStoffregen
10-27-2015, 10:00 PM
So far, all El Capitan problems have been related to USB Serial mode. I personally tested 1.26-beta1 with El Capitan. It works.

If your Teensy is already programmed as USB Serial (from an older Teensyduino before this issue was fixed), first unplug it. Make sure Teensy Loader is running. Use the Teensy > About menu to make sure it's 1.26-beta1. Turn off auto mode. Then hold the button while plugging the cable back in. Holding the button will prevent Teensy from running any code that was previously loaded. When you release the button, you should see Teensy Loader recognize the Teensy. If you turned off auto mode, it won't immediately reprogram. Then you can run Arduino with the new Teensyduino and program it with the updated USB code that works properly with El Capitan.

Massel
10-28-2015, 07:16 AM
Did this with one Teensy and afterwards all others got recognised, too.
Thank you for your always fast answers!!!

mralexgray
10-29-2015, 04:38 PM
Hi Paul. Thanks. The verify/upload process is definitely working better now, under 10.11, with this. I have a slightly different issue, but I believe it is 10.11 (10.11.2, specifically) related. When I upload the standard firmata sketch... I get the customary blinky-blinky.. but am unable to connect via firmata to the board... coincidentally, after that first connection attempt, all usb/serial communication stops working (although I do see the device listed under dev, ie. /dev/tty.usbmodem935591)! The board stops responding, regardless of pushing reset, disconnecting, etc. and the entire USB system goes to heck. At this point I can't even view the USB section in System Profiler (see below). My only option at this point is to restart. Once back up, everything is fine, i believe, until again trying to connect to the firmata device (a teensy 3.1 in my case). Any advice?

5389

McLyw
10-30-2015, 01:27 AM
So far, all El Capitan problems have been related to USB Serial mode. I personally tested 1.26-beta1 with El Capitan. It works.

If your Teensy is already programmed as USB Serial (from an older Teensyduino before this issue was fixed), first unplug it. Make sure Teensy Loader is running. Use the Teensy > About menu to make sure it's 1.26-beta1. Turn off auto mode. Then hold the button while plugging the cable back in. Holding the button will prevent Teensy from running any code that was previously loaded. When you release the button, you should see Teensy Loader recognize the Teensy. If you turned off auto mode, it won't immediately reprogram. Then you can run Arduino with the new Teensyduino and program it with the updated USB code that works properly with El Capitan.

Hi Paul, I reinstalled 1.26-beta1, and programmed 'EchoBoth' firmware to teensy3.1 according your method. Then I use CoolTerm to test. I clicked 'Connect' button, sent '81' and can receive 'USB received:129', it is great!But I do many times like 'Disconnect' - 'Connect' - sent 81, sometimes USB serial no response just after I 'Connect' then sent '81'. The funny thing is if I sent '81' three times, USB serial will give me a correct response, then data transfer is normal. I test many times, if usb serial no response after I 'Connect' and sent '81', always sending '81' three times will activate usb serial. I test this for the self test of my EKG system, the code in OS X Yosemite is fine, but in El Captain, it can not go through. I do not know what was wrong? Could you please give me some advice?

5397

mug
11-01-2015, 10:38 AM
Does running this 'add-on' also for working with the Arduino Software with the UNO Board ? Nowadays a can't use the UNO because my iMac (El Capitan) can not communicate with the board because of wrong USB driver. I write about my problem here (last post)
https://forum.arduino.cc/index.php?topic=354969.0

retospect
11-25-2015, 05:05 AM
Hi Paul,

Here's another El Captian serial issue:

When I run the code below on 10.11.1 using Arduino 1.6.6 and Teensyduino 1.26, and watch the console, I get the occasional clobbering in random places - some data gets overwritten by data following it.

/dev/cu.usbmodem does not appear to have this problem, but pyserial (2.7) with python (2.7.10) show a similar same loss of data. Previous OSX versions did not do this noticeably. Any suggestions?

The output:


123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCD


The sketch:

void setup() {
Serial.begin(9600);
}

byte count = 0;

const byte BUFSIZE = 64;
byte buffer[BUFSIZE] = {0};

void loop() {
count = '1';
for(int i = 0; i < BUFSIZE; i++) {
buffer[i] = count++;
if (count > 'Z') {count = '0';}
}
buffer[63] = '\n';
// while (!Serial.available()) {};
Serial.write(buffer, 64);
}

PaulStoffregen
11-25-2015, 08:04 AM
Does this problem appear if I just watch the data arrive in the Arduino Serial Monitor? Or do I have to use pyserial somehow?

I guess my main question is what exactly do I actually run with El Capitan to see the problem?

How frequently does this occur? Should I expect to see it within seconds, or do have I to collect data for hours, days, or weeks?

defragster
11-25-2015, 08:09 AM
FYI - in case it relates - the SerialMon of IDE 1.6.6 is worse than ever on Windows 10. It is Ctrl-R de-activated during compile and never comes back.

After each compile the IDE (USB) SerMon window must be closed and re-opened on my system as the old one sits there 'grayed' out showing nothing.

It probably doesn't relate as not only is this windows but the above issues don't seem to call out the IDE SerMon - but just in case. I'm going back to TYQT to see if it has developed any new odd behavior. Besides I've got two active Teensy display units and SerMon is one port only.

retospect
11-25-2015, 08:23 AM
It shows up randomly, about once a second, in the Arduino Serial Monitor.
They are easy to spot because the lines stick out (all the ones I've seen so far).
I can make a PySerial test as well, if that helps.


Does this problem appear if I just watch the data arrive in the Arduino Serial Monitor? Or do I have to use pyserial somehow?

I guess my main question is what exactly do I actually run with El Capitan to see the problem?

How frequently does this occur? Should I expect to see it within seconds, or do have I to collect data for hours, days, or weeks?

retospect
12-09-2015, 01:20 AM
Hello Paul,

I've written a little sketch and a python program to easily demonstrate this problem.

On El Capitan, I get 14-15% of dropped/mangled 64 byte blocks consistently.
On Yosemite, I get 0% dropped consistently.
I am using Teensyduino 1.26 and Arduino 1.1.6.

I'd be happy to help fix this in any way :)

Output:
python ./readbackTest.rb
Getting Port
Found Teensy at /dev/cu.usbmodem1346771.
Opening port
Starting to read
Last error:
Expected: 44444444444444444444444444444444444444444444444444 4444444444444
Received: 44444444444444444444444444444444444444444444444444 44444666666666666666666666666666666666666666666666 666666666666666666


OK: 8506, Error: 1494, Error rate 14.94%

Sketch:
int i = 0;
const int MAXBUF = 10;
const int USB_BUFSIZE = 65; // 64 + 0 termination
char sprintbuf[MAXBUF][USB_BUFSIZE];

bool send_now = false;

void setup() {
Serial.begin(9600);
// Prepare some data
for (i=0; i< MAXBUF; i++) {
int j = i*111111;
sprintf(sprintbuf[i], "%06d%06d%06d%06d%06d%06d%06d%06d%06d%05d%04d\n", j,j,j,j,j,j,j,j,j,i*11111,i*1111);
}
Serial.flush();
}

void loop() {
if (Serial.available() > 0) {
char command = Serial.read();
if (command == 'b') {
send_now = true;
}
if (command == 'e') {
send_now = false;
}
}
if (send_now) {
for (i=0; i< MAXBUF; i++) {
// Send 64 bytes as fast as possible.
Serial.print(sprintbuf[i]);
}
}
}


Python script (uses pyserial):
#!/usr/bin/python
import serial
import time

# Find the port the teensy is at, for convenience
def getTeensyPort():
import serial.tools.list_ports as lp
for portDict in lp.comports():
if any("VID:PID".lower() in s.lower() for s in portDict):

#pull out the VID and PID numbers
start = portDict[2].find('=')
middle = start + portDict[2][start:-1].find(':')
end = middle + portDict[2][middle:-1].find(' ')
VID = int(portDict[2][start+1:middle], 16) #convert hex string to int
PID = int(portDict[2][middle+1:end], 16)

if VID == 5824 and PID == 1155:
print "Found Teensy at {}.".format(portDict[0])
return portDict[0]

# If we have found and returned none, it is an issue.
raise Exception("Unable to find a Teensy board in USB enumeration.")

print "Getting Port"
port = getTeensyPort()
print "Opening port"
ser = serial.Serial(port)
time.sleep(0.01)
ser.write("b\n") # begin to send
ser.flush()
ok_count = 0
error_count = 0
lastError = "No Error"
print "Starting to read"
while (ok_count + error_count < 10000): #
line = ser.readline()
expected = (line[0] * 63)
if (line.rstrip() != expected.rstrip()):
lastError = "Expected: {}\nReceived: {}".format(expected,line)
error_count = error_count + 1
else:
ok_count = ok_count + 1

ser.write("e\n") # finish sending
ser.flush()

print "Last error:\n{}\n".format(lastError)

print "OK: {}, Error: {}, Error rate {}%".format(ok_count, error_count, 1.0*int(10000.0*(1.0*error_count/(error_count + ok_count)))/100)

5710
5711

brashtim
12-09-2015, 09:47 PM
I have run the test script on Windows 7 64 bit and I also get 0% dropped. It looks like the issue is with El Capitan

moizd
12-09-2015, 10:34 PM
I ran the script on a 64-bit windows 10 laptop and got:



C:\sourcecode\Sketchbook\serial_speed_straight>ver

Microsoft Windows [Version 10.0.10586]

C:\sourcecode\Sketchbook\serial_speed_straight>python readbackTest.py
Getting Port
Found Teensy at COM5.
Opening port
Starting to read
Last error:
No Error

OK: 10000, Error: 0, Error rate 0.0%

No errors.

Persilja
12-09-2015, 10:40 PM
I ran the test script on Linux, Fedora22 (64bit) with no errors:


$ python serialdebug.py
Getting Port
Found Teensy at /dev/ttyACM0.
Opening port
Starting to read
Last error:
No Error

OK: 10000, Error: 0, Error rate 0.0%

PaulStoffregen
12-14-2015, 11:38 PM
I'm working on this now. I've got a Teensy and USB protocol analyzer connected to an El Capitan machine and it's reproducing the problem. Teensy appears to be sending properly. There's no corrupted or incomplete packets, so this is really starting to look like a bug in El Capitan. I have hunch about the bug (based purely on guesswork about what Apple might be doing), and I have a couple ideas for a workaround.

PaulStoffregen
12-15-2015, 12:24 AM
Ok, here's my first attempt at a workaround.

To use this, control-click on Arduino and then select "Show Package Contents". Then navigate to Contents > Java > hardware > teensy > avr > cores > teensy3. Replace the usb_serial.c in that folder with the copy attached to this message.

Please let me know if this helps? Honestly, I'd just a guess on my part. I really don't know why El Capitan is losing the incoming data, but this is the only thing I can guess that might help.

PaulStoffregen
12-15-2015, 12:28 AM
If this does help, and if you're feeling like experimenting, try editing the tx_full_count threshold. It's at line 203:



// work around Mac El Capitan bug
if (tx_full_count >= 15) {


Currently I have this set very low, only 15 packets. My hope is it can be raised, since this is adding extra USB communication that will (very slightly) impact performance for everyone, on Windows and Linux too, only to work around this problem on El Capitan. The larger this threshold, the less impact on performance.

Also, you can uncomment that other code to blink the LED. Don't forget to use pinMode(13, OUTPUT) in setup(). Then you'll be able to see the LED show some indication of how much it's having to do this extra USB communication.

defragster
12-15-2015, 05:38 AM
Paul: You no doubt saw I was working on a serial sketch. The couple times I looked at my case no using send_now I thought I was seeing all my data, but I pulled down your updated usb_serial.c and saw missing data. I went back to TD 1.26 and I see missing data - but less of it. No data is lost when send_now is part of the print process.

I am on Windows 10 - IDE 1.6.6 with TD 1.26 using TYQT as my terminal program.

That sample selectively incorporates send_now in the test cycle and when I run with send_now I see 40,000 lines of data and 2,788,892 bytes of data transferred to TYQT in 11.297 seconds.

With the same parameters if I take out the send_now my external throttling keeps it sending on the same schedule [not entering the printing code] transfer time is 11.470 seconds. Given the same timeframe ideally there should be no lost data? But with new new code several hundred lines [~900] and 64K bytes are never accounted for in TYQT, and the old code lost hundreds fewer lines [~300] and only 14k bytes on the couple runs I cut and pasted.

TYQT was working poorly but was updated in past days and works right with send_now and will properly run over 1000 iterations of my code without fail. Versus as you may have seen IDE SerMon won't complete 3 passes.

If you want to run my code against your analyzer maybe it will help: 5821

As it is it will make a 40K line run without send_now then toggle to send now operation - [a 10 second wait in between]

If it thinks the output is slowing the system the throttle (usec wait) will be raised and then it will restart. There are Booleans up front to control some behavior as commented.

There are starting throttle values - on my system send_now code needs over 280 to run right without seeing slowdown - I have it init to 300 usecs. The non-send_now running at 300 shows the data loss, but thinks it runs fine as low as 60-90 usecs throttling - with more data loss - but no delay generated by the USB code.

You may not have seen I ran the same test against the LC and the completion times are nearly the same - I'm not sure how closely I viewed the data.

<edit after a few thousand runs and no reboot - my TYQT is being astable.>

PaulStoffregen
12-15-2015, 01:21 PM
@defragster - Could you please start a new thread for this? Let's consider this Windows 10 case with complex Teensy-side code separately from the Mac El Capitan issue with very simple code on Teensy.

This Mac issue probably should have been its own thread too. Off-topic doesn't matter to me, but two issues in the same thread is harder, because I track stuff to investigate by saving links to threads. When I consider this Mac issue resolved, I'll forget all about your issue by deleting the link from my TODO list. That's why I need it in a separate thread. Posted in the bugs+suggestions section would also be nice, but not essential.

PaulStoffregen
12-15-2015, 04:32 PM
Arduino 1.6.7 might release within the next few days, prompting another Teensyduino release. If anyone having issue on El Capitan is reading, *now* is the time to give this a try!

defragster
12-15-2015, 05:35 PM
@defragster - Could you please start a new thread for this? Let's consider this Windows 10 case with complex Teensy-side code separately from the Mac El Capitan issue with very simple code on Teensy.


Will do when I get time again. Seemed like similar behavior in a common file from the code I saw - maybe I misread. I don't expect it is hard to lose data on Win 10 - the example code is only complicated by ways to adjust/alter the behavior to minimize or focus. Prior 'El Cap' example here would probably do it or my code stripped down to 10 lines of a firehose.

<edit> - I saw ElCap example had send_now but not noted that it worked differently when used? My note was saying Win 10 has data loss - EXCEPT when send_now is used from what I saw on closer examination.

Headroom
12-15-2015, 07:44 PM
If another Teensyduino release is around the corner, perhaps the multicast addition to EthernetUDP.h/.cpp that is now in the Arduino Ethernet library can also be added to Teensyduino. That would be nice!

defragster
12-16-2015, 03:07 AM
I put the post #21 code in the IDE and that worked on Win 10 watching it against TYQT. In running & seeing that code I see mistook local var send_now for Serial.send_now().

On Win 10:: I put a variant of my write function output in p#21 sketch and saw it fail against TYQT - with or without send_now(), but in the same case it runs okay against IDE SerMon - until it runs up the buffer memory and other GUI oddities happen. I'll get back to it when TD_1.27 goes beta, and if I can make it fail against IDE SerMon I'll make a new thread.

retospect
12-16-2015, 03:48 AM
Thank you Paul,

I've tried this a few times with different tx_full_count comparison values, and have not gotten it to work - the failure rate is essentially the same as before, and it seems not to change when I change this value.

Any other things you figure are worth trying?


If this does help, and if you're feeling like experimenting, try editing the tx_full_count threshold. It's at line 203:



// work around Mac El Capitan bug
if (tx_full_count >= 15) {


Currently I have this set very low, only 15 packets. My hope is it can be raised, since this is adding extra USB communication that will (very slightly) impact performance for everyone, on Windows and Linux too, only to work around this problem on El Capitan. The larger this threshold, the less impact on performance.

Also, you can uncomment that other code to blink the LED. Don't forget to use pinMode(13, OUTPUT) in setup(). Then you'll be able to see the LED show some indication of how much it's having to do this extra USB communication.

maxbot
12-16-2015, 05:39 PM
Any idea when you have time to continue working on the MTP Disk stuff, Paul ?

I am really forward to see this one working on the Teensy 3.2 without using uTasker ;)

balducien
01-02-2016, 04:22 PM
Good evening, I have the same problem that Massel has been reporting (https://forum.pjrc.com/threads/31043-Teensyduino-1-26-Beta-1-Available?p=86576&viewfull=1#post86576). The loader won't even recognise that there's a teensy 3.1 plugged in.

I followed the steps in Paul's response (https://forum.pjrc.com/threads/31043-Teensyduino-1-26-Beta-1-Available?p=86611&viewfull=1#post86611) (unplug teensy, start teensy loader 1.26-beta1, turn off automatic mode, plug in teensy while pressing button). Nothing happened, the loader just kept saying "Press button on Teensy to manually enter Program mode". Any attempts at uploading sketches failed. I tried this with the IDE 1.0.6 and 1.6.3, and with a variety of teensyduino/teensy loader versions too. Still no success.

I know it's not the teensy that is dead, it still runs a sketch I uploaded some time ago with no problems.

I'd be extremely grateful to hear about anything else I can try, as the project that I use the teensy for is rather important.

My current setup is: Macbook pro mid-2012 15" (9.1) with OSX 10.11, Arduino IDE 1.0.6 and 1.6.3, both with the teensy loader 1.26-beta1.

Headroom
01-02-2016, 04:34 PM
I that case,

Upgrade to Arduino 1.6.6 and use Teensyduino 1.26beta#3 (https://forum.pjrc.com/threads/31351-Teensyduino-1-26-Beta-3-Available/page3)

Or you can try Arduino 1.6.7 and Teensyduino 1.27b2 (https://forum.pjrc.com/threads/32273-Teensyduino-1-27-Beta-2-Available)

BTW, both of these work perfectly here on my mid 2010 i7 iMac.

balducien
01-02-2016, 07:01 PM
I that case,

Upgrade to Arduino 1.6.6 and use Teensyduino 1.26beta#3 (https://forum.pjrc.com/threads/31351-Teensyduino-1-26-Beta-3-Available/page3)

Or you can try Arduino 1.6.7 and Teensyduino 1.27b2 (https://forum.pjrc.com/threads/32273-Teensyduino-1-27-Beta-2-Available)

BTW, both of these work perfectly here on my mid 2010 i7 iMac.

Neither of these two worked. It still says the following in the Arduino "IDE"'s console:



Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

Headroom
01-02-2016, 07:04 PM
Perhaps try a number of different USB cables. Some USB cables, specifically the ones that come with chargers don't have the wires for data and only contain the wires for the 5V.
This has deceived many new users.

defragster
01-02-2016, 07:43 PM
@balducien - per @headroom and this thread Not-able-to-upload-sketch-to-Teensy (https://forum.pjrc.com/threads/32283-Not-able-to-upload-sketch-to-Teensy)

A bad cable was the problem there. If that doesn't work with a known good cable - moved to other ports - follow that thread to post #6 which is version of Paul's steps - plugging in with button pressed - but patiently pausing before releasing - has helped on Windows. Do you have a second Teensy by any chance you can plug in?

Also you might try TYQT (https://forum.pjrc.com/threads/27825-Teensy-Qt?p=90594&viewfull=1#post90594) as it may give GUI feedback when a device is detected - though usually only in USB mode except when it is programming it.

balducien
01-03-2016, 08:46 AM
@balducien - per @headroom and this thread Not-able-to-upload-sketch-to-Teensy (https://forum.pjrc.com/threads/32283-Not-able-to-upload-sketch-to-Teensy)

A bad cable was the problem there. If that doesn't work with a known good cable - moved to other ports - follow that thread to post #6 which is version of Paul's steps - plugging in with button pressed - but patiently pausing before releasing - has helped on Windows. Do you have a second Teensy by any chance you can plug in?

Also you might try TYQT (https://forum.pjrc.com/threads/27825-Teensy-Qt?p=90594&viewfull=1#post90594) as it may give GUI feedback when a device is detected - though usually only in USB mode except when it is programming it.

First things first, something very suspicious is that the voltage between the GND and Vin pins is only 1.2V, and from GND to 3.3V it's only 0.95 V! (If my multimeter is to be trusted, it's a new one and I haven't tested it a lot. It does show the correct voltages on an ATX PSU though) There doesn't seem to be a significant current being drawn, the teensy stays at ambient temperature. This is the case with two different computers, so I doubt that the USB output is faulty.

I did previously try two different cables, both of which can transfer data from and to an android phone, without success.

TyQt does indeed show a teensy (see screenshot below), however:
- The options in the "upload" tab are greyed out.
- It only shows the teensy for about ten seconds after plugging it in, and only if the teensy has been powered on by something other than USB right before that (if I plug the teensy in several times in a row, it only shows up the first time). Strangely enough it also doesn't show anything if I press the button on the teensy while plugging in.
- Even if I do everything "correctly", it sometimes shows up and sometimes doesn't.

http://i.imgur.com/uSBegRY.png

Even if I try to upload a sketch while the teensy is still visible in TyQt, it doesn't respond to the IDE's reboot request.

defragster
01-03-2016, 09:36 AM
The voltage is an interesting indication. Was anything ever soldered to it? Has it ever been programmed or running the factory blink? Is it blinking?

TYQT can only see it in USB mode, or when in bootloader mode and will still reset it then when online. The factory blink doesn't have USB and it will go missing from TYQT.

If you press the button on a healthy Teensy it will go to Bootloader and be visible to TYQT. TYQT will then list it and it can be reset with the circular arrow ICON.

PaulStoffregen
01-03-2016, 10:17 AM
the voltage between the GND and Vin pins is only 1.2V, and from GND to 3.3V it's only 0.95 V!

That's definitely a hardware failure! The PTC "fuse" is probably getting really hot. (be careful it you try touching it....)

If other stuff is connected to Teensy, disconnect everything you can. Hopefully you'll see the voltage return to normal.

balducien
01-03-2016, 10:48 AM
That's definitely a hardware failure! The PTC "fuse" is probably getting really hot. (be careful it you try touching it....)

If other stuff is connected to Teensy, disconnect everything you can. Hopefully you'll see the voltage return to normal.

Well shit... The fuse is indeed getting really hot (I'm assuming it's the white component between the USB connector and the regulator). There is indeed a lot soldered to it, and it's a huge mess (http://i.imgur.com/4Tu8abh.jpg) so this is going to take some time :/ If I manage to find the culprit, will I have to replace the teensy or should the current one still work? Or will I only know that once I disconnect everything (or at least the power pins) and try to program the teensy again?

PaulStoffregen
01-03-2016, 11:38 AM
If I manage to find the culprit, will I have to replace the teensy or should the current one still work?

Usually Teensy survives shorted external circuits drawing way too much current, as long as they're only powered by Teensy and not suppling their own power (and there's not something like a switched inductor or coil creating huge voltage spikes). But this certainly isn't good. If this Teensy does survive this ordeal, I'd mark it as suspect/abused and avoid putting it into anything you want to last and be reliable long-term.

balducien
01-03-2016, 02:59 PM
I fixed it! Woohoo!!!!

It wasn't my circuit that drew too much current, it was the new ATX PSU that was powering everything. When I applied power to the teensy via USB, my circuit was still connected to the PSU (may not have been my greatest idea), which snatched itself a few 100 mA. Luckily all the electronics are powered by slip rings, so I can just put a sheet of paper in between the contacts, and my laptop can communicate with the teensy again.

Thanks a lot for pointing me in the right direction, this is not the first time. Have a nice day!

enbraing
01-09-2016, 04:24 AM
Hi, doing a small project using XBEE S6B via the SPI bus, and having trouble getting the XBEE to connect to any wi-fi network.

enbraing
01-09-2016, 04:25 AM
I am attempting to configure wifi parameters by SPI from Teensy 3.1 (latest firmware), but it is not connecting.