Strange Characters Received with UART

[AE104]

Hello,

I use the STM32F767 microprocessor on my PCB design. After sending back the converted data to a PC with UART, I got strange characters (in Picture1). Normally, I am supposed to get the numbers like in Picture2. The characters look like Chinese but I didn't get any meaning even though I try to translate them to Google. There is the only one module that may generate these characters. It is an HC05 Bluetooth module. Do you think that the malfunction of the Bluetooth causes this problem or any other source of that?

Thank you,

[Tesla DeLorean]

>>The characters look like Chinese but I didn't get any meaning even though I try to translate them to Google. 

Well I think you won the Internet today with that one sir..

Looks like you have the baud rate or clocking wrong, or you're missing a signal inversion. Got a scope? Inspect the signal, confirm the bit rate matches expectations, and the serial is correctly orientated.

Check HSE_VALUE define matches your actual choice of external clock frequency.

You can't push CMOS levels into an adapter expecting RS232 levels

[AE104]

@Community member​ 

Thank you for your interest! Also, I heard as a first time 'you won the internet today' expression.

Actually, I double-checked the baud rate and clock frequencies, and they are correct. Honestly, I don't know the signal viewing for the Bluetooth. Should I probe on the TX pin of the Bluetooth to see the square shape signals?

HSE_VALUE is also correct.

I didn't understand the last comment.

[Bob S]

What device is your F767 UART connected to? From your comments I am guessing it is connected to some sort of Bluetooth modem? If so - what voltage levels is the Bluetooth module expecting - CMOS (3.3V and GND) or RS232 (typically +3V to +12V and -3V to -12V). That is what @Community member​ means by "pushing CMOS into adapter expecting RS232".

Set your code to transmit continuous "U" characters (binary 01010101). Look at the F767's UART TX pin on a scope and you should see a square wave and 1/2 your baud rate.

[Tesla DeLorean]

Well the signal looks similarly repetitive to your expected output, so if you had submitted it to SETI they'd probably indicated it was a sign of life.

RS232 has different, and inverted logic levels, the output from the STM32 is more text-book in nature, ie normally high, low going initial start bit, etc.

If this is the input to the STM32 (UART RX) put the scope on that, the briefest high and low times being indicative of the baud rate from the device sending the data.

As Bob suggest if you send a continuous stream of U's out the UART TX pin you should be able to see a square wave, and confirm that is also consistent with the expectations of both devices.

How the blue-tooth plays into this at a broader level I don't know, but an HC05 outputs CMOS levels, so baud rates is my best guess here.

Also not sure on the exact source of the notepad data, you could send a periodic "Hello World" from the STM32 to the terminal from the debug/serial source, and confirm if that part of the channel is working as expected.

[AE104]

Thank you very much @Community member​  and @Bob S​ ! I found that the error is a file encoding issue. When I open the file with UTF-8, I see the numbers correctly. I just wonder why one file is not encoded correctly, and the others are fine. Anyway, maybe this is related with the Matlab(read comments run in a Matlab interface) issue.

By the way, I noted U characters sending for the Bluetooth test. It is a great idea. Thank you all!

[S.Ma]

Is it the same HC05? Baudrate programmed differently?

Any chance a wrong command sent to HC05 while it was not paired?

Is the STM33 using a precise clock source?

[AE104]

Yes, all settings are the same. Yes, I use a 25 MHz external clock source.

[Bob S]

Look at the first 1 or 2 bytes in the file that only reads correctly when opened as UTF-8. There are probably binary bytes that the OS and/or your editor are interpreting as UTF byte order markers, 0xfeff, I believe).