T4.1 Serial (USB) some times stop transmitting, reception still works

Status
Not open for further replies.
T

toto_brico

Member
Hello all,

We are designed a "big" application/prog base on a Teensy 4.1 with the main features :
  • USB/Serial that communicate with a PC (VB prog used during 4 years with others ECU) connected with the USB connector and the Serial library @ 115.2kbit (only "usefull" for the VB app), this com is always runing, 2/3 message in Tx and Rx per seconde
  • Serial1 to communicate with other device @ 57.6kbit, messages are send to the device only some times acording to input events(physical or CAN)
  • Serial2 for a DMX communication (all time runing)
  • Can Bus com (with other T4.X)

We spent the last 2 weeks at identified clearly the dysfunctional of our programme and making trap for it... without a great succes, hence my post.
The issue is that it happens that communication, with the PC by the serial, stop, only for the transmitting, the reception still work and the program still work in real time (no crash)
All the serialX are managed with serialEvent() function.

We don't know why and which reason can cause that. The only way, we have is to restart the Teensy.

BUT, our program works well during days (with Serial and serial2(DMX), and Can bus) if we don't use the Serial1. Each time the Serial stop working, is when we sent many messages on the serial1.
So, my question is : Can you thing that something on Serial1(hardware serial) can cause an dysfunctionning of serial(USB)?

During my investigation (forum and libraries), I realized that it could happen that we send more chars than the SERIAL1_TX_BUFFER_SIZE. Can be the cause of our issue?
To be sure, is the SERIAL1_TX_BUFFER_SIZE at 64 bytes by default, if we don't used Serial1.addMemoryForWrite() function?

Many many thanks in advance for your help or advice,

We used T4.1 and Teensyduino 1.55
we also try with a PC on Win7 and others in Win10
 
Can anyone said me which can cause the serial/usb stop to write (but not to read), and what can I do to make a diagnosis.
Also, we linked Serial.RTS() and DTR to outputs (with led), and we observe that RTS fall down when Teensy stop transmit... logic.

I realy appreciate any ideas.:confused:

Edit : in my previous post, i write a mistake
  • Serial2 to communicate with other device @ 57.6kbit, messages are send to the device only some times acording to input events(physical or CAN)
  • Serial1 for a DMX communication (all time runing)
 
2 bugs were recently found & fixed in teensy_serialmon.exe, where data Teensy transmitted would not be sent to the Arduino Serial Monitor window. As a quick check, in the Tools > Ports menu you should see the COM port listed twice. The "Teensy Ports" one uses teensy_serialmon.exe and a highly optimized serial monitor. The "Serial Ports" one uses Java JSCC and the normal serial monitor. Try selecting the Serial Ports version, and then open the serial monitor again. While the serial monitor window is open, you can visually confirm which is used because the normal Arduino version has a drop-down menu to change the baud rate (which isn't actually used for USB virtual serial).

If your program transmits a lot of data at very high speed, save your work first! The "Serial Ports" version is very inefficient. Teensy 4.0 can transmit so fast that the Arduino IDE quickly runs out of memory and crashes. The "Teensy Ports" version and teensy_serial.exe were created to try to make Arduino stable at those speeds... but it is a very difficult thing....

As you can see on the lengthy 1.56-beta1 thread, there are also bugs in the Windows driver and maybe on the Teensy side when a huge amount of data is transmitted at very high speed. So far the only 100% reliable solution for Windows is to limit the speed you transmit. Even just a few mircoseconds between lines of text is usually plenty.
 
Dear Paul,

Thank a lot for your reply and all of your work too.:D

I fact we don't use arduino ide/monitor. We have your own application.
Until now, we use a basic ECU with FTDI UART/USB bridge whitout any data delivry control mechanism and it still work like a charm.
The main advantage with that, is that we can plug and unplug as we want.

Also I read in teensy4x's presentation that there is a "Emulated Serial" :
The USB Type settings lacking Serial use a HID interface to emulate serial. In these modes, your PC or Mac will not detect a COM port or serial device, but you can still use Serial.print() to send text to the Arduino Serial Monitor.

I think is that I need.
So, how can I emplemented it on the Teensy side?
 
@PaulStoffregen
PaulStoffregen said:
when a huge amount of data is transmitted at very high speed
Click to expand...
In fact, we only send juste a char[~60] each 100ms....

@Frank B
Thank for your time and your reply
Frank B said:
https://social.msdn.microsoft.com/Fo...e-it?forum=wdk
https://social.msdn.microsoft.com/Fo...bser?forum=wdk
Click to expand...
Initialy we worked on W7 and all the posts said that due to that, so, we decided to connect a new PC with W10...

So, I'm a bit disappointed because I propably forgot or miss something to do thing so simple that I used to since my studdies (20 years ago).
Is there any way (registers or functions... to check) to diagnosed what cause serial stop to send?
 
toto_brico said:
In fact, we only send juste a char[~60] each 100ms....
Click to expand...

Oops, no. That should work reliable. It is reliable. Can you post your code? If possible a short example that just shows your problem.
We see this issue often, and it's most of the time just a little bug/issue in the user code.. it helps when more eyes look over it :)
 
Indeed the CDC driver buffer corruption bug happens only with sustained fast data transfer, typically in the 5 to 30 Mbyte/sec range. You definitely don't need to worry about that Windows bug if you're only sending 600 bytes/sec! It's only a concern if you're sending huge amounts of data at sustained maximum speed, where the driver ends up buffering hundreds of megabytes.

In Windows XP, Vista, 7, 8, the CDC driver had other bugs, particularly a very annoying bug where unplugging the USB cable or rebooting Teensy (which to your PC looks as if the cable were unplugged) while any program had the COM port open would cause the COM port to not work the next time you reconnected, even if hours or days later. Very confusing. Microsoft finally fixed that terrible bug in the 2nd Windows 10 tech preview, so you definitely want to use Windows 10 (or 11).

As a first simple test, I'd suggest trying a variety of different programs on the PC side to receive your data. The 2 different ways with Arduino Serial Monitor and a program like CoolTerm would be a good start. If you're running your own custom program to receive the data, first just do the easiest thing (no dive into code) and make sure the problem happens the same way with a few other programs receiving and showing the data.

Troubleshooting with traditional serial not using flow control is so simple. But USB protocol is very complex and fundamentally has flow control integrated at a very low level, which is awesome in so many ways, but when you have a problem it's very difficult to know if the root cause is on the device side or host side of the USB cable. Try to rule out a bug on the PC side software by testing with a few other terminal emulators to receive the data.
 
it helps when more eyes look over it
Click to expand...
Thanks a lot for your proposal.
This is really a big code, and we are trying to cut it to trap the bug.

We suspect that a pump drived by another Teensy T4.0 which is connected by CAN to the main T4.1 at 20m can cause the stop transmission... ?!?? --> we are lost :rolleyes:
I read in a post that we can reduce the USB speed @12Mb/s instead of 480. But, I no longer find it.
Also, if I reduce speed, is there a new limitation of buffer?

Code: 
#define CDC_RX_SIZE_480       512
  #define CDC_TX_SIZE_480       512
  #define CDC_RX_SIZE_12        64
  #define CDC_TX_SIZE_12        64
 
Status
Not open for further replies.
Back
Top