2010-05-12 08:27 AM
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
#hyperterminal2010-05-13 03:33 AM
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 Grom2010-05-13 04:03 AM
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 Stefano2010-05-13 05:13 AM
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 Grom2010-05-17 03:46 AM
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: GromPosted: Thursday, May 13, 2010 2:18 PMSubject: 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 Grom2010-06-20 12:49 PM
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 Col2010-06-28 09:14 PM
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 Col2010-06-28 09:19 PM
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 Col2010-07-11 03:05 PM
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.