Sometimes flaky program download

Status
Not open for further replies.

Raptor

Active member
It's weird, sometimes I can modify and download to the Teensy 3.6 repeatedly without a problem and at other times the download halts and reports errors that aren't there. I notice when this happens that when I go into Tools that the Port appears grayed out. Pressing the boot button on the Teensy 3.6 sometimes works and sometimes it doesn't. Is there any setting I can tweak to make the download 100% dependable? Just to be clear it's not a problem with the program as the very same program will download fine when the board decides it want to. Also, I'm running a Windows 10 PC with IDE version 1.8.3.


Brian
 
It's weird, sometimes I can modify and download to the Teensy 3.6 repeatedly without a problem and at other times the download halts and reports errors that aren't there. I notice when this happens that when I go into Tools that the Port appears grayed out. Pressing the boot button on the Teensy 3.6 sometimes works and sometimes it doesn't. Is there any setting I can tweak to make the download 100% dependable? Just to be clear it's not a problem with the program as the very same program will download fine when the board decides it want to. Also, I'm running a Windows 10 PC with IDE version 1.8.3.


Brian

I get similar behaviour (Also T3.6, Win10 and IDE1.8.3) when I decide to download while USB is active (mostly using usb_audio)only way is to disconnect Teensy from USB port and reconnect. So I conclude USB system gets into a state from which it does not recover .

Also, when using a HUB from time to time USB is screwed up and con only be sanitized by disconnecting the hub from PC.
 
I've seen something perhaps similar on one USB port on my year old Dell Win 10 machine. I move to another port and it runs fine to program reliably.

note - the Teensy button takes it to 'Program' mode - not boot or restart or reset in any fashion.
 
I also suspect there's an issue with how the Teensy handles USB ports but in my case the only device connected to any USB port is the Teensy. So, there's nothing else competing for attention on the USB buss. I should also add that if I connect the Teensy to a different USB port on my PC (laptop) that it pretty much won't see the Teensy and I have to plug it into the original port. Interestingly, I also have a Arduino Mega 2560 and I never have problems with it communicating and it doesn't matter which port I use. My best guess is that the Teensy is not as robust at communications as the Mega 2560 -- I use the same PC and in both cases the only device connected to USB is either the Mega 2560 or the Teensy 3.6.

I'm not ragging on the Teensy, the performance when it does run is superior and has much greater memory.


Brian
 
I also suspect there's an issue with how the Teensy handles USB ports but in my case the only device connected to any USB port is the Teensy.

As Paul wrote in another place, the Teensy USB stack is a complete own development. So, I guess, improvements are possible (Volunteers step forward)
Comparing to other MCUs, the execution speed may matter.
I do not know the Mega 2560, does it have a dedicated USB chip?
 
I may be wrong but Mega has a dedicated USB hardware chip that is 'always on' {like UNO not Leonardo? }. The Teensy as WMXZ notes uses native on processor chip USB hardware - is very robust. However it goes away when the Teensy is not running (like Leonardo). It messes with Windows idea of the world (mice/printer/keyboard/camera/scanner/Flash/HDD's, etc are generally static or removed with warning) when Teensy leaves some second and then is back in another mode then gone and back again after programming and 400 ms later looking to SPEW whatever it is told to. Uno and perhaps Mega with dedicated USB hardware chip are always connected unchanged even during programming and MCU restart.

With a good cable on a good USB port ( hubs can be perfect - USB2 can be perfect - USB3 can be a bit slower to connect ) - but depending on the combination between the Teensy&cable and Windows the transitions don't always go without making Windows do a double take or worse want to give up on the port.

So even with a perfect implementation ( which is may nearly be - of course interacting with user sketch at the same time can have it in an odd place ) - the improved utility speed and support and lower part cost/space of the native processor USB - the fact that programming makes it sign out and sign in leaves end functionality under the direction of Windows - and that is far from ideal in a device that can be extremely talkative - then change - leave - return without warning.

Generally for my time with Teensy - unless my code messes up - multiple reprograms can number in the dozens or more in a session with no problem - and the last year+ has been mostly T_3.6's.

You might forum search TyCommander and integrate it to Arduino - I generally do. It handles programming and SerMon internally and handles the Serial stop - Program - Serial Restart as a single program and can control the timing and gets SerMon back online MUCH faster ( it used to be almost 2X slower - last I saw was 5X or 6X to get IDE SerMon to hand SerMon to Teensy ).
 
What does "at other times the download halts and reports errors that aren't there" really mean? Is there an error message? Remember, we can't see your screen. Nobody can know what you're seeing if you do not give a screenshot.

The only description is " I notice when this happens that when I go into Tools that the Port appears grayed out". I'm trying to understand if the error you see is the port menu, or if you're observing a correlation between this error and something happening in that menu? If it is merely a correlation, it's not clear if you observe the port menu this way before or after the error. I also can't tell what settings you're using. So many unknowns....

Screenshots of the tools menu normally and in this condition would help quite a lot. So would a screenshot or video clip of the whatever error happens. If the error only appears momentarily, perhaps use your phone or a camcorder to record it? Often the easiest way to share a video clip is uploading to an unlisted video on youtube.

To really get to the bottom of any problem, at the very least you'll need to collect logs of what really happen. There are two of these.

1: Teensy Loader has a Verbose Info window. It's hidden in the Help menu. When you open the Verbose Info, it has a "Log" menu which lets you save all the info to a file.

2: The Arduino-side utilities log their activity to a file named "teensy_reboot_log.txt". On Windows and Mac it's likely to be in temporary folder which the operating system hides. You'll probably need to use search to find it. Knowing the exact name of the file "teensy_reboot_log.txt" hopefully can help.

Please try rebooting your computer, so you're starting fresh. Then recreate the error. Take screenshots or record a video, so you can show us exactly what it really happening. Collect those 2 log files.

We can talk at length about how the USB stuff works or is supposed to work, but it's all just blind guessing if we can't see what really happened on your screen, and without those 2 log files, there won't be enough info. I know it requires more work, but I hope you can post a reply with all this info. I really would like to understand what's going wrong and find a way to solve it. If there's something Teensy isn't doing correctly, I definitely want to investigate and fix that for everyone.
 
No Problem when using IDE #1.9.0Bld31 with Teensyloader 1.42b2 on below 'Repro Port' or other port.

Did get back to my Repro Port - same behavior I was seeing some time back even with another cable - Only with TyCommander and only observed on one port of my trusted/long used USB2 Hub.

When I moved the same cabled T_3.6 to a different port on the same HUB the TyCommander 'offline' behavior stopped. TyCommander also works on at least 2 other direct USB ports. When I found the behavior I just swapped ports and have been working no problems for some time with multiple T_3.6's and likely hundreds of uploads.
 
I may be wrong but Mega has a dedicated USB hardware chip that is 'always on' {like UNO not Leonardo? }. The Teensy as WMXZ notes uses native on processor chip USB hardware - is very robust. However it goes away when the Teensy is not running (like Leonardo). It messes with Windows idea of the world (mice/printer/keyboard/camera/scanner/Flash/HDD's, etc are generally static or removed with warning) when Teensy leaves some second and then is back in another mode then gone and back again after programming and 400 ms later looking to SPEW whatever it is told to. Uno and perhaps Mega with dedicated USB hardware chip are always connected unchanged even during programming and MCU restart.

With a good cable on a good USB port ( hubs can be perfect - USB2 can be perfect - USB3 can be a bit slower to connect ) - but depending on the combination between the Teensy&cable and Windows the transitions don't always go without making Windows do a double take or worse want to give up on the port.

So even with a perfect implementation ( which is may nearly be - of course interacting with user sketch at the same time can have it in an odd place ) - the improved utility speed and support and lower part cost/space of the native processor USB - the fact that programming makes it sign out and sign in leaves end functionality under the direction of Windows - and that is far from ideal in a device that can be extremely talkative - then change - leave - return without warning.

Generally for my time with Teensy - unless my code messes up - multiple reprograms can number in the dozens or more in a session with no problem - and the last year+ has been mostly T_3.6's.

You might forum search TyCommander and integrate it to Arduino - I generally do. It handles programming and SerMon internally and handles the Serial stop - Program - Serial Restart as a single program and can control the timing and gets SerMon back online MUCH faster ( it used to be almost 2X slower - last I saw was 5X or 6X to get IDE SerMon to hand SerMon to Teensy ).


I don't think the Mega 2560 has a dedicated USB chip but it does have 4 hardware based UARTS.

I've tried several different cables with no help to the problem -- I either have the problem or I don't and I know of nothing I've done to make the difference.


Brian
 
What does "at other times the download halts and reports errors that aren't there" really mean? Is there an error message? Remember, we can't see your screen. Nobody can know what you're seeing if you do not give a screenshot.

The only description is " I notice when this happens that when I go into Tools that the Port appears grayed out". I'm trying to understand if the error you see is the port menu, or if you're observing a correlation between this error and something happening in that menu? If it is merely a correlation, it's not clear if you observe the port menu this way before or after the error. I also can't tell what settings you're using. So many unknowns....

Screenshots of the tools menu normally and in this condition would help quite a lot. So would a screenshot or video clip of the whatever error happens. If the error only appears momentarily, perhaps use your phone or a camcorder to record it? Often the easiest way to share a video clip is uploading to an unlisted video on youtube.

To really get to the bottom of any problem, at the very least you'll need to collect logs of what really happen. There are two of these.

1: Teensy Loader has a Verbose Info window. It's hidden in the Help menu. When you open the Verbose Info, it has a "Log" menu which lets you save all the info to a file.

2: The Arduino-side utilities log their activity to a file named "teensy_reboot_log.txt". On Windows and Mac it's likely to be in temporary folder which the operating system hides. You'll probably need to use search to find it. Knowing the exact name of the file "teensy_reboot_log.txt" hopefully can help.

Please try rebooting your computer, so you're starting fresh. Then recreate the error. Take screenshots or record a video, so you can show us exactly what it really happening. Collect those 2 log files.

We can talk at length about how the USB stuff works or is supposed to work, but it's all just blind guessing if we can't see what really happened on your screen, and without those 2 log files, there won't be enough info. I know it requires more work, but I hope you can post a reply with all this info. I really would like to understand what's going wrong and find a way to solve it. If there's something Teensy isn't doing correctly, I definitely want to investigate and fix that for everyone.

Paul, thanks for taking the time to respond...

I failed to write down the specific error message but it occurred during the program download from IDE to Teensy 3.6. If/when this happens again I'll try to document whatever messages I see and report back. This may be a bit as I'm currently running a program on the Teensy that isn't scheduled to end for another day -- I built a Peltier module test rig that's driven by the Teensy 3.6 so it's tied up during the test which last about 25 hours.

OK, so I see your info on the loader log and Aruino log so I'll look into that and perhaps also record some video when I'm able to do that, again on hold while doing the Peltier module test.

Again, thanks for looking into this and I'll endeavor to provide the info you seek in a day or so.


Brian
 
I don't think the Mega 2560 has a dedicated USB chip but it does have 4 hardware based UARTS.

Brian

I find this Arduino Mega 2560 Datasheet that suggests it does - like the UNO - have offchip hardware that the Pin 0/1 UART uses for USB connect - and it doesn't drop each time it is programmed - keeping Windows and the IDE connected more 'normally':
Pins 0 and 1 are also connected to the corresponding pins of the ATmega8U2 USB-to-TTL Serial chip.
 
concerning downloading to Teensy, it is interesting to observe both the behavior of the device manager (re-flash on changing USB status) and connection lights on a USB hub.
It seems that PC needs always some time to react to new status, this may also depend on CPU/memory load and priority settings.
 
concerning downloading to Teensy, it is interesting to observe both the behavior of the device manager (re-flash on changing USB status) and connection lights on a USB hub.
It seems that PC needs always some time to react to new status, this may also depend on CPU/memory load and priority settings.


I'm not using an external USB hub with my laptop. The laptop has three USB ports in total and no other devices are connected to the USB ports.


Brian
 
Well I'm still doing some project testing and my laptop and Teensy 3.6 has been powered on without interruption for about a week now and in that time the only download issues I've had were shortly after powering up. Since that first few attempts failed I've not had a single problem with program download. I still have some more testing before I can cycle power but I'm beginning to think the problem is related to powering up and that once that's been established and comm has been established the download works as it should. Once I'm done with the immediate project testing (Peltier module testing) I'll cycle power and see if the problem reappears. I'll set up my camera to record.

Paul, if you see this and I am able to duplicate the problem and record that on video is there some way to send that video to you? I could upload to YouTube, but I'd rather have you look at it first.


Brian
 
An unlisted video on youtube is perfectly fine. Feel free to email me the link if you like, but please also include a link to this thread so I can see the background info.
 
OK Paul, when I get a chance to test this I'll upload an unlisted video and provide you the link -- probably a couple days...


Brian
 
OK, I completed the project testing I was doing and attempted to document the problem I was having. Again though, I had been connected with the laptop and running for more than a week straight without a problem so I thought it might have something to do with powering up. So, I shut everything down and unplugged the Teensy 3.6 USB cable from the laptop as many PC's provide power to USB even when off. I then powered up the laptop, then plugged in the Teensy USB cable, loaded the Arduino IDE, loaded in the program to download, and then clicked the download button. Normally the download takes about 4-8 seconds give or take but as I was recording this it took more than a minute before the progress bar completed and the boot-loader popup come up -- BUT, after waiting the full minute it looks like all is well.

So, I think what I've done in the past was to assume the download was hung and then pressed the boot-loader button on the Teensy or attempted to re-download the program before the progress bar and download was complete and it was THAT that caused the errors. Still, I'm puzzled why it takes a minute to complete the download when normally it's just a handful of seconds. I also tried the other two USB ports on the laptop and after waiting the minute all the ports appear to work as they should.

So, I think the blame belongs to my impatience and suspicion that the long download was because the system had hung. And, since messing with it at that point did cause a problem this reinforced the idea that there was a problem.

Paul, why does the first download after powering up take so much longer than the subsequent ones?


Brian
 
When the IDE fresh starts it builds ALL the core library for the Teensy based on the chosen Teensy, compile and type options for the chosen speed etc. This shows on the progress gauge and takes the 'extended' time seen on initial build.

Intermediate build objects that do not change are cached and re-used making subsequent builds and uploads happen much more quickly.

Until the IDE exits or some required compile option is changed those cached objects persist for re-use. With Verbose Compilation Output on you'll see things like "Using precompiled core" on rebuilding.
 
OK, that explains the time difference. And, now that I know that I'll know to wait instead of assuming it had hung. The first time download takes longer but knowing it's a one time deal I think we have resolved the problem...


Brian
 
With Verbose on for compile in File / Preferences you get a stream of action as it progresses in the lower pane. Good to turn verbose on and scan for 'warnings' - otherwise only errors that cause stoppage show and some warnings are critical to address.
 
The Arduino IDE is supposed to show a progress bar as it compiles all the code. Sadly, the animation isn't very smooth. Perhaps if Arduino actually managed to animate that progress bar every half second, it'd be much more apparent it's actually working on compiling your code?

Recent versions of Arduino have moved management of the build process to a program made with Google Go language, so working on this is now much more complex because it involves communication between two processes built from 2 separate code bases in 2 different languages.
 
Status
Not open for further replies.
Back
Top