Join GitHub today
Port becomes unresponsive after receiving large amounts of data #1778
Summary of Problem
HOWEVER, if I use a different terminal app and manually type in the "debuglines-1000%", it never hangs, it continues to respond each subsequent call, even if I send 10,000 lines.
Code to Reproduce the Issue
See more recent updates down in my comments. I have source for mbed and Arduino and a new node stress script...
Not sure how to provide the target code, since I doubt you would want to spend time flashing a STMicro device. But here is the JS code...
Versions, Operating System and Hardware
Can you share the debug output from setting the DEBUG environment to
Can you also try adding a callback to the
@HipsterBrown Oh, and here's is the debug response after the subsequent "debuglines-10000%" command. (I added a little extra code on the remote device to let me know it's parser is ready by printing a string.)
Thanks for sharing that. What does it look like when it is working on Windows?
I'm starting to think there is some issue between the polling required on max/linux systems vs the file events on windows. The
means there is no available data and the poller is just sitting waiting for more.
So it looks like Win10 is now also not behaving properly when I send back 10k lines, the second write command is ignored. Here's the debug=* output (using node v11.6.0 and email@example.com)..... am I using serialport wrong? I thought write was async... what happens on subsequent serialport.write() commands? Does serialport buffer them, or are they sent if the target UART is ready to receive? Do I need to do anything special when calling back-to-back write()?
Hmm... Now I wonder if it is the hardware? Odd, I'm using both latest mbed and STCubeMX versions which are essentially the same underlying UART CMSIS. Let me try an arduino...
Windows log. I'm expecting after the 10,000th line to see five lines, i.e. write('debuglines-10000%') and then write('debuglines-5%')...
Hi again @HipsterBrown Nick,
I started my stress experiments again and moved to win10 to use the latest serialport:
I tested on 5 targets [board // stack // compiler (status)], only one passed:
Arduino UNO // arduino libs // avr-dude (pass)
And the node script is modified to blast out more data: 10,000, then 10,000, then 5. This series caught another board failure (the pearl gecko passed 10,000+5 and failed 10,000+10,000+5).
Only the Arduino passed. The other four configurations hung without an error, throw, or onerror. The STM boards hung after the first run of 10,000 lines. The Pearl Gecko made it through the first 10,000 and then 10 lines of the next command.
The debug logs look the same. It sits there waiting for read data, and the write() callbacks have no error.
Where in the C++ library for serialport should I start dropping the printfs(). And how does one begin recompiling local npm modules? I've never debugged a native NPM module.
I'm going to close this for now because I think it is related to the firmware stack and the UART FIFO depth. E.g., can the non-ISR parse loop be overflowing / dropping data while the lengthy print loop transmits? I'm not sure why the Arduino has no problem with this, but I don't think it is related to serialport. Thanks for the help @HipsterBrown