Teensy 4.1: Capture serial break

[Uwe]

Hello!
Is it possible for a Teensy 4.1 to recognise a serial break sent from the PC side?
And if yes: How?

Uwe.

P.S.: The "PC" side is a PC running a Java program using SerialPort.sendBreak(...) from package JSSC to send a break.
I don't know if this break is interpreted correctly by the FTDI chip on the Teensy board...

 

[tonton81]

instead of .print(), do a Serial.write() to view the actual byte, after the sendBreak the last byte would be the break, then you can check for that. Serial.print doesn't print it obviously but you can still check for that byte value in Serial.read()

 

[Uwe]

I don't understand your answer at all. Can you be more precise? e.g. "instead of .print(), do a Serial.write() to view the actual byte". I don't use .print() ... and Serial.write() cannot be used to view bytes... I'm confused...

 

[KurtE]

A couple of quick notes. There is no FTDI chip on the Teensy boards. They all have processors with built in USB support.

I am not sure what the PC sends when you do that in Java.

I believe what @tonton81 was suggesting is write simple sketch on a Teeny4.1 and see what is sent to you.


Something as simple as:

void setup() {
    while (!Serial && millis() < 5000) ; // wait up to 5 seconds for Serial port...
    Serial.begin(115200);   // baud rate does not mater here but need to put in something.
}

void loop() {
  if (Serial.available()) {
    Serial.print("New Data time: ");
    Serial.println(millis(), DEC);
    uint32_t count = 0;
    while (Serial.available()) {
      int ch = Serial.read();
      Serial.print(ch, HEX); 
      Serial.print(" ");
      count++;
      if ((count & 0x1f) == 0) Serial.println();
    }
    Serial.println();
  } 
}

Warning typed in on fly so maybe issues, but idea is when it receives data from Serial it simply does hex dump of all of the data it received.
I did put in some quick and dirty count where only 32 characters will print on same line... Also shows some timing of when each one came in...

So hopefully you can find out if the break sent some specific character... Note could go fancier by also printing out ASCII characters for areas in
the printable ascii range, but hopefully this will be enough

 

[Uwe]

I had to fix your code a little bit but I understand your intention.
Problem is: 'Break' is no valid character, it's the result of the transmit line being low for a longer time than a frame lasts. So you can't read a 'break' from the input buffer because there is less than nothing in the input buffer
There should be some kind of status register that indicates a break...
Something like 'getPortEvent()' which reports a break interrupt (BI).

P.S.lease think of random binary data being transferred to the Teensy. If you react on a specific character as a 'break' character you will have many (unwanted) breaks.

 

[defragster]

Found this: deepbluembedded.com/uart-pic-microcontroller-tutorial/

Framing Error

A UART receiver will detect a Framing Error when it does not see a stop bit at the expected time after a start bit. As the start bit is used to identify the beginning of an incoming data frame, its timing is a reference for the remaining bits. If the data line is not in the expected state (high) when the “stop” bit is expected (according to the number of data and parity bits for which the UART is set), the UART will signal a framing error. Which means the timing between data bits, start bit, and stop bit is somehow for whatever reason is just messed up! A break condition on the line is also signaled as a framing error.

 

[KurtE]

Actually I understand what a break signal is. Maybe not exactly the underlying timing...

BUT what you are mentioning is what it would do on a hardware UART. What is unclear is what does it do with a USB connection? And it may or may not be handled in the same way on the PC. It may depend on which lower level driver (FTDI vs ACM... )

I thought I would suggest the above as a quick and dirty way to see if maybe there was some indicator you could detect.

This may be more of something that @Paul may be able to answer. For example it may be that maybe it is signaled in a different way, like maybe some USB event, or what I may suspect, maybe it sends a packet with no data...

Why I might suspect it: is in usb.c I see:

		// fall through to next case, to always send ZLP ACK
	  case 0x2321: // CDC_SEND_BREAK
		endpoint0_receive(NULL, 0, 0);
		return;

Now maybe that is nothing.

But in usb_serial.c in the static void rx_event(transfer_t *t)
method is a test for len > 0...

The else case (it does nothing except to re queue the transfer...

So if it were me, I would probably add some form of debug to the else clause and see if you hit it with this... But as it is a .c file you can not directly call things like Serial.print... I have hacked it in the past where put in temporary CPP file with simple wrapper function to call Serial.print... Maybe a few different options... Make the functions with C calling... and then extern it in the file I am debugging.

Or sometimes I use the pre made wrappers, for Serial1 like (serial_print(const char *p) and then output over Serial1...

And if this is the case, then maybe we need some form of API or method on the Serial object to detect when this happens...

But again that is more a question to Paul.