UART information is shifted by 1 byte when I connect my STM32G474RE directly to my PC and use a terminal program to send information to control things. It fixes itself after resetting the board.

[Alexander Stankov]

For example, if I send 1000, it will be received as 0100 on the STM board. I send what I received in the Rxcallback function. My program doesn't work, so I know this is the case. This issue stops after I hit the RESET switch on my board. Now, my issue is that for my university project, the STM board is locked in a box. It can't be reset. So how do I fix this issue in software, if possible? Or will I have to do some soldering...

The CubeIDE also does the same thing when debugging, it restarts the board after the initial connection to it. Is it because I was debugging it beforehand? The UART is in async mode so it should not need any clock synchronization, but are there any stop/begin specific characters in stm32, I haven't heard of such a thing.

[TDK]

> For example, if I send 1000, it will be received as 0100 on the STM board.

There's nothing on the STM32G4 that is going to transpose the first two characters. Most likely there is a bug in your software, or the data on the line isn't what you expect, perhaps due to the terminal program buffering data. Do you have pullups on the RX line? What exactly are the hardware connections?

Also likely is that your receive calls are out of sync with what's being sent, so you're getting the end of one transmission, plus the start of another.

[Alexander Stankov]

I'm using a micro-USB cable to connect to my PC via USB. In the .ioc file of my program the 2 pins (RX/TX) for the LPUART have the following settings:

GPIO Mode; Alternate Function Push Pull

GPIO Pull-up/Pull down; No pull-up and no pull-down

So I don't think I have a pull-up or down? Is it OK for that to be the case with LPUART pins? I don't get any errors after resetting my board, if there are they are code-related.

I've set my inputs as pull-downs.

I'm quite a novice and really don't have a lot of technical know-how.

[Paul1]

1. If you have another IC driving the pins, then pullup/pulldown will just draw more power from the IC driving the signal, best to not enable pullup/pulldown.
2. If the other IC is "open-collector"/"Open-Drain" then you need a pullup to put signal in known state when neither IC is driving the signal
3. If the other IC can be disconnected (as in example1 below) then need pullup on UART_RX.
4. UART signals idle high (start bit is low), so if nothing connected the UART_RX should have a pullup.
5. If your STM's USB isn't used then you could set it up as a VCP (Virtual Com port), then you wouldn't need the UART-USB interface IC.

Example1: I have boards with a header that allows connecting an FTDI UART 3.3V cable, so the MCU needs pullup on UART_RX when cable not connected

Example2: USB VCP

• Note that the VCP won't output until after USB init is called.
• You have to handle case of nothing connected so diagnostics won't block code running when USB can't send.
• You can easily put on a USB-C connector, without power, which allows use of convenient unpolarized USB-C cables.
• See attached: usb_vcp_20210520PR.zip

Paul

Paul

[Paul1]

Does your "protocol" have any sync mechanism, incase there is some noise on startup/powerup?

Typically for console user input a CR Carriage return terminates one input, and preps for next (or an LF, or a CRLF sequence).

Maybe set your code to expect a CR before the 1000, and expect a CR to terminate the 1000 (as when you type on a keyboard to a PC console). i.e. idle waiting for a CR, then print a prompt asking for the input value.

Paul