stm32/periph/uart: extra byte transmitted on first transmission

[bergzand]

After testing the slipdev driver on a nucleo-f446, it appeared to me as if an extra 0xFF byte is transmitted by the UART driver. As somewhat described in #8041 (comment), this can be explicitly triggered with slipdev by having the node transmit a frame. An initial 0xff byte should appear as first byte (and by doing so crash the tunslip6 application).

More a suspicion than a confirmed bug, it would help if somebody can reproduce this (or refute this bug), I still have to test if this 0xff byte is also added to the UART interface of the shell.

Oh and close and ignore this issue if it is caused by the low on reset nature of the hardware and the active-low of UART.

[bergzand]

Here is a hexdump from the serial console:

$ hexdump -v -C < /dev/ttyACM0 
00000000  ff 6d 61 69 6e 28 29 3a  20 54 68 69 73 20 69 73  |.main(): This is|
00000010  20 52 49 4f 54 21 20 28  56 65 72 73 69 6f 6e 3a  | RIOT! (Version:|
00000020  20 32 30 31 37 2e 31 30  2d 64 65 76 65 6c 2d 38  | 2017.10-devel-8|
00000030  39 32 2d 67 34 37 65 34  38 2d 67 69 73 74 65 72  |92-g47e48-gister|
00000040  65 6e 2d 68 65 61 64 73  2f 6d 69 72 69 36 34 2f  |en-heads/miri64/|
00000050  67 6e 72 63 5f 69 70 76  36 5f 6e 69 62 2f 66 69  |gnrc_ipv6_nib/fi|
00000060  78 2f 73 6c 69 70 2d 61  64 64 72 2d 72 65 73 2d  |x/slip-addr-res-|
00000070  65 78 63 65 70 74 69 6f  6e 29 0a 57 65 6c 63 6f  |exception).Welco|
00000080  6d 65 20 74 6f 20 52 49  4f 54 21 0a 3e 20        |me to RIOT!.> |

That first 0xff is not supposed to be there. On the pyserial it also displays as �main(): This is RIOT! (Version: 2017.10-devel-892-g47e48-gisteren-heads/miri64/gnrc_ipv6_nib/fix/slip-addr-res-exception)

[haukepetersen]

I can roughly confirm this. Out of my head I think I remember seing this on some STM boards, but not all of them. So if I am right, this is effecting only some stm32 family members, though I can't say which ones.

Just happen to have a nucleo144-f746 on my desk: for this board I cannot confirm that behavior, everything is fine:

2017-11-17 16:05:28,650 - INFO # main(): This is RIOT! (Version: 2018.01-devel-531-ge01c2-prag)
2017-11-17 16:05:28,651 - INFO # Hello World!
2017-11-17 16:05:28,655 - INFO # You are running RIOT on a(n) nucleo144-f746 board.
2017-11-17 16:05:28,659 - INFO # This board features a(n) stm32f7 MCU.
2017-11-17 16:05:28,801 - INFO # main(): This is RIOT! (Version: 2018.01-devel-531-ge01c2-prag)
2017-11-17 16:05:28,802 - INFO # Hello World!
2017-11-17 16:05:28,807 - INFO # You are running RIOT on a(n) nucleo144-f746 board.
2017-11-17 16:05:28,810 - INFO # This board features a(n) stm32f7 MCU.
2017-11-17 16:05:28,963 - INFO # main(): This is RIOT! (Version: 2018.01-devel-531-ge01c2-prag)
2017-11-17 16:05:28,964 - INFO # Hello World!
2017-11-17 16:05:28,969 - INFO # You are running RIOT on a(n) nucleo144-f746 board.
2017-11-17 16:05:28,972 - INFO # This board features a(n) stm32f7 MCU.
2017-11-17 16:05:29,117 - INFO # main(): This is RIOT! (Version: 2018.01-devel-531-ge01c2-prag)
2017-11-17 16:05:29,118 - INFO # Hello World!
2017-11-17 16:05:29,122 - INFO # You are running RIOT on a(n) nucleo144-f746 board.
2017-11-17 16:05:29,125 - INFO # This board features a(n) stm32f7 MCU.

(pressing the reset button a couple of times...)

[haukepetersen]

On paper, line 61 of the uart driver

    /* set TX pin high to avoid garbage during further initialization */
    gpio_set(uart_config[uart].tx_pin);

should prevent the 0xff byte being send, but as it seems this does not work for every stm board.

@bergzand could you maybe play with that line a little bit and see if you can prevent that garbage byte from being send somehow?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@bergzand could you maybe play with that line a little bit and see if you can prevent that garbage byte from being send somehow?

Ping @bergzand?

[benemorius]

In uart_init_pins(), move gpio_set() to before gpio_init(). IIRC stm32 allows that but it may not. I think that should resolve this but I don't have an stm32 to test on.

This is related to #12380 and #12612

Based on the nature of the cause, I'd guess that slower boards are more susceptible to showing this bug.

[benemorius]

@bergzand or perhaps @haukepetersen could you test #14417 and see if it resolves this issue?

Using a board with a slower MCU might help to reproduce it. If not, speeding up the baud rate should help reproduce it too. Actually yeah just speed up the baud rate as much as possible. That should do the trick.

[maribu]

I used the following patch:

diff --git a/cpu/stm32/periph/uart.c b/cpu/stm32/periph/uart.c
index 5cba9470ec..0815009e3e 100644
--- a/cpu/stm32/periph/uart.c
+++ b/cpu/stm32/periph/uart.c
@@ -160,6 +160,9 @@ static inline void uart_disable_clock(uart_t uart)
 
 int uart_init(uart_t uart, uint32_t baudrate, uart_rx_cb_t rx_cb, void *arg)
 {
+    gpio_t signal_pin = GPIO_PIN(PORT_D, 2);
+    gpio_init(signal_pin, GPIO_OUT);
+    gpio_clear(signal_pin);
     assert(uart < UART_NUMOF);
 
     /* save ISR context */
@@ -221,6 +224,7 @@ int uart_init(uart_t uart, uint32_t baudrate, uart_rx_cb_t rx_cb, void *arg)
     }
 #endif
 
+    gpio_set(signal_pin);
     return UART_OK;
 }

And connected a logic analyzer to the UART port and to PD2 (label SIG in the images):

Above, you can see some noise on TXD while SIG is low (that is, during uart_init().

Same data, zoomed in.

Even more zoom.

[maribu]

So, it is possible to set the GPIO after the periph clock is enabled but before the pin is configured. There is still some flickering that my logic analyzer picks up, but the integrated programmer/debugger/UART-adapter of Nucleo-F446Re will ignore it. I guess that is good enough.

[maribu]

The fix is actually different than described above. Please refer to the PR description of #14426 for a description of the cause of the issue and how I suggest to fix it.

[aabadie]

Fixed by #14426.