Long delay for Serial1.begin() / missing updateBaudRate()

[gicking]

I have a library which provides LIN communication across a variety of architectures and serial interfaces. To generate LIN BREAK signal, I temporarily reduce the baudrate, send 0x00 and revert to the original baudrate.

However, when porting to Nucleo-STM32L432KC I found that changing the baudrate via Serial1.begin() and subsequent Serial1.write() adds a pause of ~1B before BREAK, and between BREAK and SYNC, which causes LIN slaves to time-out. Note that this is not due to Serial1.begin() but really an additional latency between begin() and write()which seems to be ~1B at the respective baudrate (see screenshots)

Can you please check what causes this long latency and improve it? Alternatively add a new method updateBaudRate(), similar to ESP32 (see here) with smaller latency? Attached please find a small sketch and screenshots to show what I mean.

Reproduce
Run this sketch and measure TxD and testpin with a logic analyzer
STM32_switch_baudrate.zip

Expected behavior
Time to switch baudrate and subsequent byte is very short on other platforms.

Screenshots

Desktop:

• OS: Linux / Ubuntu
• STM32 core v2.12.0
• Arduino IDE version: 2.3.7
• STM32 core version: 2.12.0

Board:

• Name: Nucleo-STM32L432KC

[fpistm]

Hi @gicking

About updateBaudRate, it is not a missing API. It is not part of the Arduino Core API reference:
https://github.com/arduino/ArduinoCore-API/blob/master/api/HardwareSerial.h

Anyway it can be added. But prevent sketch to be fully Arduino compatible.
Feel free to provide a PR for this.

From my point of view your sketch is not correct.
You have to call Serial.end() to properly deinit the instance else some variables are not properly initialized.
Anyway I doubt it will speed the time between begin and write. Begin made a lot of configuration pin, clock , IP configuration,.... relying on HAL API.

Note: please when code is small, add the code directly in the issue instead of a zip file. It ease reading and avoid download. All information are in one page.

[gicking]

Hello again,

ad 1) good point! Without additional latency between begin() and write() I would rather stick with Arduino compatibility. However, the observed latency prevents me from generating a LIN frame which starts with a 0x00 at half baudrate (=BREAK).

ad 2) correct again: an additional end() before begin() has no impact on the latency :-(

Note that end() and begin() only take ~34µs, i.e. very fast. Therefore I doubt that it is caused by HAL configuration of pin, clock , etc.. Also note that the delay is always ~1B long, i.e. longer for 9600Baud than for 19200Baud. This seems to indicate that e.g. some transmit ongoing flag is not cleared or so.

[fpistm]

Serial is managed by IT and so when you do a write the function return before the send is effective.

[fpistm]

Could you try this code:

#define TESTPIN     PB_5        // 11 Assuming Nucleo L432KC
#define SERIAL      Serial1     // USART1 via TX=PA9=D1, RX=PA10=D0

// instanciate here with Rx, Tx
HardwareSerial SERIAL(PA_10, PA_9);

void setup() {
  SERIAL.begin(19200);
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(TESTPIN, OUTPUT);
}

void loop() {
  uint8_t   Rx[10];
  
  digitalWriteFast(TESTPIN, HIGH);
  SERIAL.begin(9600);
  digitalWriteFast(TESTPIN, LOW);
  SERIAL.write((int) 0x55);
  SERIAL.flush();
  digitalWriteFast(TESTPIN, HIGH);
  SERIAL.end();

  SERIAL.begin(19200);
  digitalWriteFast(TESTPIN, LOW);
  SERIAL.write((int) 0x55);
  SERIAL.flush();
  digitalWriteFast(TESTPIN, HIGH);
  SERIAL.end();
  delay(1);
  digitalWriteFast(TESTPIN, LOW);

  digitalWrite(LED_BUILTIN, !(digitalRead(LED_BUILTIN)));

  delay(500);
}

[gicking]

Sure, no problem :-)

1. pinMode() does not work with PB_5, needs to be 11 or D11. Don't know if this is expected or not
2. with pinMode(D11, OUTPUT) I see no noticeable improvement

[fpistm]

OK. Thanks.
No problem with pinmode just forgot to change it.
And no idea about the time. As it mainly relies on HAL api.

[gicking]

hi again,

to get to the bottom of this, I went down to the STM32 register level. In summary: when the UART is re-enabled it takes the duration of 1B before something can be sent. So it's actually the hardware, not even HAL :-(

However, I found 2 solutions for my library problem:

1. update the baudrate register (BRR) online, i.e. without prior UART disable. According to the RM this shouldn't be possible, but it still works

2. enable the UART LIN mode and request sending a BREAK via USART_RQR_SBKRQ

For my project both are fine, so I will stop bothering you :-)

However, maybe you want to consider adding a setBaudrate() method. Basically copy the part of HAL_UART_Init() which calculates and sets the baudrate, but without UART disable/enable

PS: here is the source used for above tests

main.c

[gicking]

I guess that ESP32 and ESP8266 have similar issues, which is why these Arduino cores provide updateBaudRate() methods, see here and here