Teensyduino 1.26 Beta #1 Available

Status
Not open for further replies.
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.
 

Attachments

  • usb_serial.c
    8.3 KB · Views: 344
If this does help, and if you're feeling like experimenting, try editing the tx_full_count threshold. It's at line 203:

Code: 
                                                // 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.
 
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: View attachment USB_Throttle2.ino

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.>
 
@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.
 
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!
 
PaulStoffregen said:
@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.
Click to expand...

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.
 
Last edited:
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!
 
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.
 
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?

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

Code: 
                                                // 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.
Click to expand...
 
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 ;)
 
Mac won't recognise teensy

Good evening, I have the same problem that Massel has been reporting. The loader won't even recognise that there's a teensy 3.1 plugged in.

I followed the steps in Paul's response (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.
 
Last edited:
I that case,

Upgrade to Arduino 1.6.6 and use Teensyduino 1.26beta#3

Or you can try Arduino 1.6.7 and Teensyduino 1.27b2

BTW, both of these work perfectly here on my mid 2010 i7 iMac.
 
Headroom said:
I that case,

Upgrade to Arduino 1.6.6 and use Teensyduino 1.26beta#3

Or you can try Arduino 1.6.7 and Teensyduino 1.27b2

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

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

Code: 
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.
 
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.
 
@balducien - per @headroom and this thread 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 as it may give GUI feedback when a device is detected - though usually only in USB mode except when it is programming it.
 
defragster said:
@balducien - per @headroom and this thread 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 as it may give GUI feedback when a device is detected - though usually only in USB mode except when it is programming it.
Click to expand...

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.

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.
 
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.
 
balducien said:
the voltage between the GND and Vin pins is only 1.2V, and from GND to 3.3V it's only 0.95 V!
Click to expand...

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.
 
PaulStoffregen said:
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.
Click to expand...

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 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?
 
balducien said:
If I manage to find the culprit, will I have to replace the teensy or should the current one still work?
Click to expand...

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.
 
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!
 
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.
 
I am attempting to configure wifi parameters by SPI from Teensy 3.1 (latest firmware), but it is not connecting.
 
Status
Not open for further replies.
Back
Top