Teensey 3.2 Teensey Loader 1.24 Issues

I

Ivo

Member
Hello,
I have an identical project using Teensey 3.1 and now 3.2.

All of my 3.1's upload code flawlessly. The 3.2 most of the time fails to upload.
The Teensey actually goes dark as if there was no power from the USB port as soon as I upload the code from the Arduino 1.6.5
The only remedy is to switch to a different USB port, the USB recognizes the Teensey and the RESET button must be pushed.

I am using the RAW HID but same happens if I use com port.

Also, this happens on all of my 3.2's and none of the 3.1's. I even switched to my different dev. hardware and I experience the same.

Windows 7 Pro 64 bit running as a virtual machine inside VMWare Workstation 11.1.2 and Windows 8 64 bit host.

My other dev. system that behaves the same is not a virtual machine it is Windows 7 64 Pro.
 
PJRC could speak better to this - 1.24 can support the Teensy 3.2 - but was released before it. The current version in Beta is 1.26 and it might hold a solution, and if not then it should before it is released from Beta so feedback from 1.26 might get more traction. An unzip IDE install to a virgin directory on your Win7 machine and install Teensy 1.26 beta on that copy and it should not affect the 1.24 install you have if you can't upgrade it directly. I can say I've have good success with T_3.2 and the newer Teensy software - but I cannot say I did not see some anomalies I couldn't pinpoint as it started working normally again - on Win10. Though I'm mostly using T_3.1's recently as they have the headers needed for the hardware I'm using right now.
 
PaulStoffregen said:
Does this problem happen if you upload something simple, like the blink example?
Click to expand...

Yes... I just confirmed that it does not care what I send to it. Blink will gag it just as well.

So to re-iterate this interesting behavior...

When I compile and upload the loader "pings" the 3.2 and at that point it goes dark...

Once I switch to different USB the 3.2 comes up alive running the previous code and if I do RESET it uploads the cued up code.

I saved a brand new log from the up-loader if you like
 

Attachments

  • 3_2_problem_Log.txt
    5.2 KB · Views: 140
Ivo said:
When I compile and upload the loader "pings" the 3.2 and at that point it goes dark...
Click to expand...

You're using very short descriptions words that don't have a lot of specific meaning for me, so I'm having a very hard time getting a clear picture of what's happening.

My guess is this is a vmware USB issue. People have tried running in virtual machines before and experienced all sorts of strange problem.

It's very likely teensy_reboot.exe is managing to open the serial port and send the 134 baud rate change, which instructs Teensy to reboot. Teensy disconnects its USB as it reboots. Teensy probably is rebooting, and appear to "go dark" because it's running the bootloader, which sits and waits for commands from Teensy Loader. The USB emulation layer probably isn't able to properly deal with a USB device disconnecting and another reappearing so quickly, so Teensy is probably sitting there in bootloader mode, but the PC isn't connecting it to the USB host in your virtual machine. Probably.

You may believe the virtual machine is just "passing through" the USB packets, but indeed it does so much more. Emulating USB properly in virtual machines is very tough. Many times before people have reported trouble with virtual machines.

You really need to test on native USB, and without any virtual machine software running. I know you said that in your first message, but somehow I really suspect this is all virtual machine related. Teensy absolutely does work reliably on Windows 7 64 bit. I have personally tested Win7 64 many, many times. It's been used by thousands of people on Win7 over the years. This particular problem just doesn't come up, except when virtual machine USB emulation is in play.
 
Paul: initial post said he is seeing the same behavior on native Win7 box. Hopefully trying the post#2 (parallel) 1.26 install on that Win7 machine something will change for more feedback?

Just more speculation - but By 'ping' perhaps these or other items from the "txt 3_2_problem_Log.txt":
18:53:59: remote cmd: "status"
18:53:59: status data sent
Click to expand...
 
PaulStoffregen said:
Teensy absolutely does work reliably on Windows 7 64 bit. I have personally tested Win7 64 many, many times. It's been used by thousands of people on Win7 over the years. This particular problem just doesn't come up, except when virtual machine USB emulation is in play.
Click to expand...

However,
I would note that both TLC and T3.2 (both with the new bootloader chip) seem to behave slightly different. While with T3.1 (old bootloader chip) I had rarely to press the program button, with the new bootloader chip, the need to press program button increased, also I have to disconnect the USB-HUB more frequently to 'reset' USB on my win 8.1 PC.

My suspicion is that interactions with the new bootloader chip are slightly changed screwing up USB communication (K20-PC).

NOTE, it does not hurt me, as during development a lot of things can happen, especially program crashes. I only want to mention my observations, without being able to provide "details to reproduce this issue" and without statistics, but Paul has complete control on the bootloader chip and its behavior, so he knows what has changed both on terms of software and hardware performance.
 
My 'anomalies' mirror what WMXZ describes. I dropped a few notes as I hit them, but they were not actionable without being able to repro or better define them. In the post above I didn't mean to say they don't happen in win10 because they do, in fact the win 10 update may have hit my Win7 machine before T_3.2 did putting one more variable in my observations. Since OSH gifted me with a double shipment I have 7 T_3.2's. I'll solder one up to the pjrc touch boards I got for the display and see if that changes from my T_3.1 efforts these past weeks. I'll even suffer the ide serial monitor instead of TYQT, which also changes things hogging usb requiring button or a tyqt gui command to reprogram.
 
Ok, I've put this on my list of issues to investigate. Realistically, there's no way I'm going to be able to work on this until after the HaD conference (Nov 14-15). Lots of other stuff will be pending by then too... so if you don't hear anything from me on this issue by the 20th, please ping me. It's on my written list, so it won't be forgotten, but it can get "buried".

In the meantime, anything you guys could do to find ways to better reproduce this problem would *really* help.

One of the huge challenges of Windows is the difference in performance and stability between freshly installed systems and well used ones with lots of software installed and a long history of accumulated data. Please understand I mostly use Linux, so my Windows test systems are pretty much fresh installs without any other software added, not even anti-virus. If any of you has access to a spare machine and time to do a fresh install, some testing to see how a clean system responds would really help.

Even if we never figure out a way to reliably reproduce this problem, I could really use some solid idea of its actual frequency. In other words, if I can't seem to make it happen, how many times I do retry? 20, 100, 500? If it really is only 1 in 100 times, I can sit here and click upload 100 times... but actually knowing I have to try 100 times would help a lot, otherwise I'd be tempted to conclude the problem isn't real around the 10th to 20th try.
 
Paul: Is there any useful thing you can think of in advance that might get added to the Verbose for Beta2 that would help show when something 'odd' happened? I got a spare machine the other day I should be able to reformat - was dreading putting Linux on it - may be able to do it fresh with Win 7 first/instead. A fresh Win7 - with all windows updates and no active antivirus - nothing but 1.6.5 and 1.26 current beta?

I've noted before the oddest set of events is when an LC is confused with a T3 - it pops up the fail note and can act funny until something medieval is done with power and cords and TeensyLoader - something takes a 'state' that needs cleared - I have not done that recently. Not LC specific: The one thing I've done to make things better is close TeenyLoader - and then re-Verify to get a hex ready - and re-open TeensyLoader to program. Any notes about these should be in the T_3.2 announce thread - or perhaps the 1.26 Beta? or even LC announce thread.

{notice you requested - I have 2 pull requests I just pinged on GitHub}
 
Just one question: do you guys put the Teensy in one of the power-down modes (VLLS3 and deeper)?

The new bootloader chip comes with a code that allows software-based debugging, but effectively disables the Teensy to do a self-induced bootload (without pressing the program button) after some time in one of those power down modes. LLS mode is exempt from that.

As the VLLS modes wake up with a Reset and restart the program, it's less probable that you use them, but it's still possible.

Jorg
 
Thank you all for helping with this ;-)

I would like to mention this in trying to be helpful and solving this issue...

The 3.1 works flawlessly on my systems (regardless of OS, etc. etc) that is just one fact that I do have.
The 3.2 fails 95% of the time as described.

There are few things that I would like to report that may possibly be relevant... from observing my systems...

After teensy_reboot.exe is managing to open the serial port and send the 134 baud rate change... the 3.2 re-boots and after that point it is as if the boot-loader is stuck.

Second... when I disconnect from the USB and re-plug to a different port windows reports checking with Windows update for driver. Hence possibly the timeout and why the 3.2 does not come back in time after the 134 byte rate change.

Third... the T3.2 when enumerating ID's reports that it is T3.1 and NOT T3.2 . This may possibly confuse things. If not... it is little of a headache for me anyway because I have sealed boxes with T3.1 and T3.2 and I would like to know what hardware runs in the box when connected.
 
Last edited:
Socketed a T_3.2, I got 14 Uploads completed and then it asked me to push the button. Saved the verbose log locally if any part of 13000+ lines needed.
IDE Upload again and it worked.
 
Could you guys try a quick hack?

Edit hardware/teensy/avr/cores/teensy3/pins_teensy.c. There's a delay on line 575. It's this code.

Could you try increasing that delay? Make it big, like 1500, just for testing sake. Does that improve this situation for Windows?
 
Works

PaulStoffregen said:
Could you guys try a quick hack?

Edit hardware/teensy/avr/cores/teensy3/pins_teensy.c. There's a delay on line 575. It's this code.

Could you try increasing that delay? Make it big, like 1500, just for testing sake. Does that improve this situation for Windows?
Click to expand...

So.... EUREKA! sort off....

Things started working flawlessly and for now I am not screwing with anything until I can confirm that things continue to be stable.
Several things to mention though... my /teensy/avr/cores/teensy3/pins_teensy.c. is clearly a different version from the one referenced by Paul. It is only 988 lines and the reference hack is on line 476.
So this may be the root cause of my problem to begin with.

here is what I did and now things work perfectly...

Changed the referenced delay starting at 100 all the way to 2500. At ~2000 the failure rate dropped by about 50%.
Next step was to change the USB type from Raw HID to USB Serial.
On USB connect and re-connect Windows again notified me that a new Com Port driver has successfully installed.

From this point on.... EVERYTHING WORKS FLAWLESSLY ! --- Thank you...

I realize that some of these steps may not have anything to do with why this started working, but w/o the hack these steps did NOT produce any results for me in the past.

In my next step I will switch back to the Raw HID ans see if anything breaks.

Thank you

Ivo
 
Ivo - see post #2 - you are running code that is OLDer - that is why yours didn't line up by the numbers.

It seems like there may be something there based on Ivo's results. I was going to do it before my next compile - but I just put on 1.26Beta2 - I will see if I get it to happen again in the next 20 uploads and then make the p#15 change.
 
I'm having troubles of this sort too, i was'nt sure what the problem is - unfortunately i changed to windows10 (i wish i hav'nt done it.. problems over problems, strange gaphics problems, old usb-devices do not work anymore, and so on), a teensy 3.2 and updated teensyduino at the same time..
sometimes the arduino-terminalwindow made trouble, most of the time re-flashing caused problems.

but i just added the extended delay (i choosed delay(1000)), and now it is *much* better.
 
Ok, looks like I need to increase that delay. It should also help with the increasingly common problem with I2C motion sensors and other chips which start up slowly.

Any idea if shorter delays, like 500, work well with native Windows?

If 1000 is what's needed to make things work great for everyone, then so be it. But it'd be nice to still have Teensy's default startup time be fairly quick, if shorter delays still work well.

I'm really depending on you guys for Windows feedback. My test machine has a clean Windows install on a fast core-i7 processor, and I mostly use Linux for development, so I just don't see these kinds of issues much.

Please let me know if you get a feeling for how much delay is really needed? I'll add it for the 1.26 release.
 
i can try lower values and report back, but of course this is not representative and only for my computer..
btw, the teensy is connected to a usb 2.0 hub
 
In my case I did not see appreciable difference before 1000 and in my case 2000 works best, this said I think that there are two separate issues.

During development the delay can be cranked up so that the uploads are stable and for final application download it can be reduced for the fast start up.
How about implementing something simple like including "dev" library that has the relevant variables and users can comment out the lib for final product.
 
I'm at 10 uploads with no 'push button' needed yet - older i5 laptop w/win10, also through a USB2 hub - last time was at #14.

Odd:
> This is new to T_3.2 ( and perhaps the LC ) - as it doesn't seem to show on the T_3.1
> I started seeing the oddities about IDE 1.6.3 or after as I recall and wanted to blame the IDE SerMon timing?
> This is a programming issue but delay is on Teensy execution? - is that because it is rebooting before the programmer can interrupt it?

I suppose 'delay(1000)' is lost in the noise as the USB has to come online before I leave setup() anyhow?

As Ivo suggests - Always handicapping the Teensy Boot Time for the sake of "Win Dev Time uploads" is nearly criminal. I typically use TYQT to monitor on Windows - this allows for multiple Teensy Uploading without button pushing as the GUI can control it. Even with a single Teensy, TYQT takes ownership of the USB so I always build w/"verify" and manually BUTTON or GUI initiate the upload manually.

I'm inclined to think this timing adjustment is a symptom being fixed - but not the problem.
 
a little, interesting observation so far:

i added the following code to setup():

vois setup() {
m = millis();
while (!Serial);
Serial.println(millis()-m);

Without changing pins_teensy.c the time reported is ~1220ms
- with the patch for pins_teensy.c (delay(500)) the reported time is reduced by this 500ms.
- with the patch for pins_teensy.c (delay(100)) the reported time is reduced by this 100ms.

it seems that delay(100) is sufficiant for my computer, maybe less. i stay with delay(100) now and test for some days.
 
for me VERY interesting:
It depends on the HUB (maybe WIN10 changed something with usb-hubs?? or is it a teensy-problem with hubs?) !!
With the other hub on my desk i need much longer time , around delay(2000) ms. it is a hub which is built into my DELL Display.
Don't know why.
 
Last edited:
I would like to circle around and mention this as it looks like it was lost in the primary discussion...

I am unable to tell the difference between T3.1 and T3.2 when connected. My point is that it looks to me like the Teensey reports "who is connected" during the upload process.
So the message "Board is: Teensy 3.1 (MK20DX256), version 1.03" should be agnostic to the version of the boot loader regardless if it was published before T3.2 ? no

I have sealed boxes with T3.1 and T3.2 mix and even though they are same ... for now they are not and so it does make difference to me.
Any thoughts?
 
You must log in or register to reply here.
Back
Top