Hardware Serial Flush

Status
Not open for further replies.

Cosford

Well-known member
/=====Update=====/
Now Resolved. As per usual, the issue was in my application code, where an occasional corrupted serial byte could cause the application to access memory beyond the size of an array. Remember kids, sanitise your input.



Hi All,

I'm currently debugging a Teensy 3.2 application which unfortunately I can share only snippets of source code currently.
Occasionally, the teensy will "freeze", ceasing execution of the main control loop (which should have a latency of no more than a couple of milliseconds).

I'm currently going through line by line to try and ascertain where exactly it may be getting stuck. One line that I'm looking at is the call to Serial2.flush(). The device is on a multi-drop serial network, where each device reverts back to a high-impedance output after transmitting. For this purpose, the simple route for me was to do the following to implement this:
Code:
_serial->begin(COMM_SERIAL_BAUD, COMM_SERIAL_TYPE);
_serial->write(transfer->transfer, transfer->length + 7);
_serial->flush();	//wait for transfer
pinMode(10, INPUT);

Is there any circumstance in the underlying hardware serial c code that could result in the serial port not sending the data and thus flush() never returning?

I'm trying to avoid trying things without sufficient cause to believe it might be the issue, or at least without a reasonable chance at getting some information as the teensy is embedded within a sealed enclosure, so reprogramming requires opening and removing the teensy.

Other libraries that the teensy is running include:
FastLED.h
Snooze library is included, although not currently called.
Audio library, not currently playing anything at times of crash.
SPI.h
SD.h
SerialFlash.h
Compiled at 48MHz


I hope to be able to soon share with you all the project I've been working on for almost the past three years. :)

Many thanks,
Cosford
 
Last edited:
Status
Not open for further replies.
Back
Top