STM8 Discovery - Hyperterminal example trouble

[spiovan9]

Posted on May 12, 2010 at 17:27

Dear friends,

I'd like to know whether someone has assembled and tested the hyperterminal application example on STM8 discovery demo board, using the ST232 driver IC.

I've done that but the hyperterminal doesn't communicate with the STM8 and vice-versa (no messages are sent between them two).

I think there could be a mistake in the schematics (PDF 16898 UM0884 page 6/23 Fig. 1). It seems to me that the DB9 pin numer 3 must not be connected with the pins 7 and 8.

Thank you very much for any info on that.

Stefano Piovan

#hyperterminal

[Grom]

Posted on May 13, 2010 at 12:33

Hello Stefano ,

Thanks for this relevant feedback . You're right , there is no connection beetween pin 3 and pin 7 and 8.

We will modify this documentation ASAP.

Thank you for your help

Regards

Grom

[spiovan9]

Posted on May 13, 2010 at 13:03

Dear Grom,

thanks for your reply-

I've tried by disconnecting pin#3 from 7 and 8, but keeping 7 and 8 connected together and unfortunately no communication yet.

Did you mean that pins# 7 and 8 have to be disconnected from each other too?

Are there any other mistakes in the schematic, in your opinon?

Thanks in advance

Stefano

[Grom]

Posted on May 13, 2010 at 14:13

I've tested the application by just connecting

Pin2 -> ST232B pin 13 (R1in)

Pin3 -> ST232B pin 14 (T1out)

Pin5 -> GND

Other conections are not mandatory in many Application case .

Hope it will solve your problem

Regards

Grom

[spiovan9]

Posted on May 17, 2010 at 12:46

Hi Grom,

I've tested the application example and it now works fine with the connection according to your suggestion.

The hyperterminal must be configure as 9600, N, 8, 1 - NO parity, despite the microcontroller UART is actually configured as ODD parity. If I put ODD parity in the hyperterminal the communication fails displaying wrong characters or the hyperterminal client window remains stucked at the cursor.

I've also tried to change the microcontroller Uart initialization params in NO or ODD. This has no still effects on hyperterminal, which wants NO parity only.

Thanks

Stefano

 

 

 

From: Grom

Posted: Thursday, May 13, 2010 2:18 PM

Subject: STM8 Discovery - Hyperterminal example trouble

I've tested the application by just connecting

Pin2 -> ST232B pin 13 (R1in)

Pin3 -> ST232B pin 14 (T1out)

Pin5 -> GND

Other conections are not mandatory in many Application case .

Hope it will solve your problem

Regards

Grom

[col_kerr]

Posted on June 20, 2010 at 21:49

Hi all.

First time on here.

I just got it working.

I didnt connect any pins other than 2 RX, 3TX & 5Gnd.

The PINS 2 & 3 need to be reversed if you are not using a NULL modem cable (with a twist in it) as most of us would not.

No mention of that anywhere I could find.

The documentation puts TX to TX and RX to RX.

As for the odd parity, I had this problem too.

When you configure Hyperterminal as it says .. down the bottom of the Hyperterminal pdf , it says to use 7 bits and odd parity. Not 8 bits and none.

It also shows a few other differences such as ASCII input force 7.

When you do all this it works.

Cheers

Col

[col_kerr]

Posted on June 29, 2010 at 06:14

06/29/2010

I just checked the um0884 document (RS232 Comms) for any changes.

Still incorrect

Just wondering how everone reading this document is getting on.

Cheers

Col

[col_kerr]

Posted on June 29, 2010 at 06:19

Hi Grom,

Just checked the UM0884 Doc. Still incorrect.

Just wondering when this UM0884 Document will be corrected as it would be causing a lot of stress out there.

Cheers

Col

[jefewest]

Posted on July 12, 2010 at 00:05

If any parity is specified, the bytes will be modified as they are transmitted by the UART.  You can get around this by configuring hyperterminal (or minicom) to specify 7 data bits, since that will mask off the parity bit.  I found this to be a problem when I created a SLIP connection with Windows, since I could find no way to specify 7 data bits (or otherwise mask off the parity bit), and so Windows never correctly received the acknowledgment string, because some of the characters had extra bits and were interpreted differently than intended.  The way I fixed this was to specify NO parity, at main.c:68:UART2_Init((u32)9600, ..., UART2_PARITY_NO, ...);, which is very common (e.g. 9600 8N1).  This allowed the characters to be transmitted with no alteration, and the SLIP connection was able to be established.