Strange USART

[nakulrao]

Posted on January 20, 2013 at 08:00

Hi

I have been attempting to send Hex values via USART to another device. When I did not get the expected results, I hooked it upto my comp and saw some strange stuff on the terminal.

the USART_SendData() function sends 16bit data. When I send 0x56 I can see 00 2A on the terminal. 0x00 gives 00 00. 0x01 gives 00 FD.

I don not know why this is happening. Can anyone please explain. Am I missing something?

Thanks in advance.

[Tesla DeLorean]

Posted on January 20, 2013 at 14:16

Send a stream of data and view it on a scope, confirm the data pattern and bit timing matches the baud rate.

The primary reason for an incorrect baud rate would be a disparity between the external crystal (HSE) and the software encoded value for it (HSE_VALUE) in the project. Make sure the project has the correct value defined.

ST has EVAL boards using 25 MHz crystals, but the DISCOVERY boards often use 8 MHz (at least VL and F4).

The secondary problem is one of electrical interfacing, the STM32 uses 3-3.3V CMOS levels for it's serial ports, this is not compatible with RS232 levels, and is inverted, you would need a level converter like a MAX232 to interface to a PC serial port.

USART_SendData() only sends 8 or 9 bits of data, as most receivers only support 7 or 8-bits sending binary bytes, and ASCII are the most practical applications.

If the receiver has framing issues, increase the stop bits, or increase the inter-symbol delay.

[nakulrao]

Posted on January 21, 2013 at 02:05

Thanks for the reply.

I am using the STM3240G eval. It has a MAX232 onboard. I have set the baud rate to be 9600 on both sides.

And isn't this the definition for send data. I thought that uint16_t means that it takes 16-bit data.

void USART_SendData(USART_TypeDef* USARTx, uint16_t Data)

[Tesla DeLorean]

Posted on January 21, 2013 at 02:45

It doesn't however SEND 16-bits.

[Andrew Neil]

Posted on January 22, 2013 at 09:11

''I thought that uint16_t means that it takes 16-bit data''

As clive1 says, the fact that it uses a 16-bit data type doesn't mean that it transmits 16 bits to the wire!

The so-called ''manual'' (which is just a help file) doesn't state explicitly, but it does give you a link to the source code - which contains:

/* Transmit Data */
USARTx->DR = (Data & (uint16_t)0x01FF); 

So it's clearly not going to send 16 bits! The STM3240G-EVAL evaluation board has a STM32F407IGH6 microcontroller: the reference manual is RM0090:

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/DM00031pdf

The description of the USART Data Register, DR, says:

''When transmitting with the parity enabled (PCE bit set to 1 in the USART_CR1 register), the value written in the MSB (bit 7 or bit 8 depending on the data length) has no effect because it is replaced by the parity''.

Remember that the USART also supports 9-bit ''multiprocessor'' mode...

[nakulrao]

Posted on January 23, 2013 at 06:05

Actually I was speaking about the function that accepts 16-bit data. I never meant to say that it sends 16-bits in hardware. The problem I am facing is that whatever I send, I do not get it on the terminal. I get completely different data. And I do not understand why that happens.

[frankmeyer9]

Posted on January 23, 2013 at 09:00

The problem I am facing is that whatever I send, I do not get it on the terminal. I get completely different data

 

Re-read clive1's first post.

This might be a baudrate problem, because the software assumes an incorrect HSE clock speed.

And it's always a good idea to use a scope, and check what actually happens.

Send some 0x00 / 0xFF bytes, and measure the transmission times on the scope. Do they match your settings ?

[John F.]

Posted on January 23, 2013 at 09:09

Also maybe try a different Terminal Program. I had similar double character problems with HyperTerminal and Windows XP64. Never found out what was wrong but TeraTerm ''just worked'' so now I use that.

[Tesla DeLorean]

Posted on January 23, 2013 at 17:00

Honestly, put a scope on it, you'd have figured what was going on 3 days ago.

You need to confirm the bit timing, it it's right you'll need to look at the receiver side, if it's wrong you have some clock set up issue on the STM32 side.