Teensy 3.1 Serial Break?

Status
Not open for further replies.
At the write with break. Again, this works ok with a Teensy 2.0. (that'll be the next post)

Showing the probes:
COM write-break-read-vi _probed.PNG

The values:
ProbeValues.PNG
 
Just uploaded EcoString.ino to a Teensy 2.0, changed to the correct serial port, got this result.

T2p0 write-break-read-vi _probed.PNG

T2p0 front panel.PNG
 
I got it running, I can see the problem with the USB control transfer (using a USB protocol analyzer), and I'm working on a fix now......
 
Ok, but turning on Execution Highlighting (Paul - the light bulb looking button in the block diagram's button bar) doesn't affect it. I set a breakpoint on the 'break write', let it sit a couple seconds, no difference. Put a 0.5s time delay between the 1st property node and the 'break write'. No change. The VI's ugly. No complaining. ;)

wBreak.PNG

In the 'real serial break' VI from the VISA library, I played with the break duration time. Default is 250msec. It ranges from 1-500msec. No change.
 
This is a bug in the Teensy 3.x USB stack. I'm working on a fix now.

There's no point digging deeper into the Labview side. I've managed to reproduce the problem here. It's definitely on the Teensy side.

I hope to have a fix later today or tomorrow.
 
Ok, here's the fix. Just copy this to hardware/teensy/cores/teensy3.

Please let me know how it works for you?
 

Attachments

  • usb_dev.c
    24.7 KB · Views: 187
Looks good. Now I'll play with it to see how robust it is - playing with the timings duff and I were kicking around.
 
My guess is the timing won't make any difference.

But please do let me know how your testing goes? Unless anything goes wrong, I'm going to push this to the github repositry, and of course that will cause it to later be in the 1.19 release.
 
PaulStoffregen said:
My guess is the timing won't make any difference.

But please do let me know how your testing goes? Unless anything goes wrong, I'm going to push this to the github repositry, and of course that will cause it to later be in the 1.19 release.
Click to expand...

I haven't exhaustively checked it, but just beating around different values for timings and the string, no problems. At least not after I put a delay in the loop. Before that, it appears LabView overflowed the USB driver queue and blue screened the machine.

I'm going to just let it bang away with minimal timings (but 100msec loop delay) for awhile with a stop on error setup. If it goes until I head out in ~an hour, it's good AFAIAC.

Thanks again. LIFA tomorrow (fingers crossed).

Hmmm... With 100msec between loops, usbser.sys crashed again... I'll try a couple other loop delays today (Friday).

From the minidump:
Code: 
Unable to load image \SystemRoot\system32\DRIVERS\usbser.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for usbser.sys
*** ERROR: Module load completed but symbols could not be loaded for usbser.sys
 
Last edited:
I can't get it to 'reliably crash', so for now I'm going to guess it's a Windows system thing and drive on unless you want me to check something else.

Here's the 'Torture Test' vi in case someone sees something I did wrong, or just wants to play with it. Again, don't judge it for pretty or as anything other than a quick and dirty test. :)

Thanks again. Off to play with LIFA...

<old vi removed - updated vi below>
 
Last edited:
Mark said:
Here's the 'Torture Test' vi in case someone sees something I did wrong, or just wants to play with it. Again, don't judge it for pretty or as anything other than a quick and dirty test. :)
Click to expand...

Just a FYI on labview, You might want the "configure" and "stop" Visa Serial stuff outside of your while loop. That way you're not constantly opening closing the serial port which can cause problems.
 
Fair enough. I'll make the change and run it over lunch. I think that tracks with the error too , "failed to open usbser.sys". I'll see if I can just replace the file above with the mod'd one. <edit> Done!?

I just tried LIFA. It worked like expected - err'd on something else. At least it looks like a LIFA thing now.

I'll keep beating on it - and report to that forum Teensy 3.0 is working now with VISA! Maybe it'll get more interest in getting it in. ;)
 
Last edited:
Looks really good. Ran the vi with minimal delays for a couple thousand runs. No errors. No BSoDs. Ship it! :)

Last rev to the vi attached. All old ones removed.
 

Attachments

  • COM Write-Read Torture Test.zip
    23.6 KB · Views: 147
'duff' got it right when suggesting moving the serial open and close vi's out of the loop would fix it. No problems after thast. I musta been making it bonkers opening and closing the port that quickly. In the least, 'twas bad programmatically on my part. <blush>
 
Mark said:
I musta been making it bonkers opening and closing the port that quickly.
Click to expand...

It also filled my USB protocol analyzer logs with a LOT of extra USB control transfers. That only took me a few extra minutes to sort out, compared the over 3 hours to install and figure out how to get Labview running.

Still, there's really no excuse for usbser.sys crashing, no matter how much USB traffic it generates. If there's an option to send a crash report to Microsoft, please do.

Based on some conversations I've had with people inside Microsoft who apparently were talking with the Windows team, it seems very unlikely Microsoft will ever fix any of the usbser.sys bugs. I've also had direct conversation with the developer at Apple responsible for their CDC serial driver, who did indeed fix bugs for OS-X 10.7 (I even sent him a Teensy-based demo which he used for testing). I've talked with Linux kernel developers who've improved the cdc_acm driver performance based on benchmarks I published. Both are pretty much the exact opposite of Microsoft, where they know their driver is buggy, but they've apparently decided it's "legacy" and won't touch it.
 
Reported it twice I think. I don't expect they'll listen to me either ;)

For what I'm seeing in LIFA now I'll try to build a test case again to isolate it.
 
Hi
I was out for a couple of days, and now I see that I come back after the battle...
Great news here, many thanks to Mark, Paul and Duff you really rock !
 
At some point you will encounter an error in the Matrix. You will be presented with a choice: to send an error message, or not to send an error message. Is there a difference?
Click to expand...

This is kind of an interesting topic for me. I have tried to use usb to ethernet devices that let you send usb devices to a remote pc via ethernet. The CDC-ACM device is the only serial device that did not work for that application. The Windows 7 driver would not recognize the device properly. It kept splitting the end points into 2 separate drivers. Finally had to use ser2net with a dedicated linux PC104 system and on the windows side I used com0com and com2tcp for the virtual serial port.

I wonder if the issue was the usbser.sys the whole time. Or just general windows stupidity.
 
Status
Not open for further replies.
Back
Top