* this is a serious bug *
Serial and TCP terminal for engineering and debugging
Brought to you by:
crun
Menu
▾
▴
2 Attachments
#76 * this is a serious bug *
(I posted this in the help and discussions forum before but now I found out how to create a ticket
- and I can attach my screen shots)
Hello,
I am working with RealTerm version 2.0.0.70 and I like it mostly because I can open and close the COM port with just one click. Over several years now I came to trust it - until these days.
I develop microcontroller software and I send data over serial line to RealTerm to see what my program is doing. Now there were some things on the RealTerm screen that seemed very strange to me and I really kneaded my brain to find the bug in my software. I reduced the function of my software until it simply sent about 100 chars repeatedly through functions that are well proven over years. Thats when I came to think "it might also be a bug in Realterm". Here are some details: 115200 Baud, 8, n, 1, Bytes are sent back to back , so now delay between stop bit and following start bit. I send a consecutive number followed by printable ASCII characteres, ended with CRLF, one line every 200msec, one line takes about 10 msec. I used a "real" COM port, not a UART to USB converter.
To identify the bug I soldered a small adapter with one SubD9 male and two SubD9 female with connected pins 5 and pins 2 respectively. So I can see the sent chars on two terminals. One was of course RealTerm, the other was Putty and TeraTerm.
To see the bug take look at numbers 3004 and 4882.
I took a look at a number of these and it seems that it is always 8 or 16 characters that are repaeted.
Well, it took me almost a week to finally find that it is not a bug in my software and I really wonder how a program that is well known and out for many years can still have such a serious bug.
Martin
OS is win 7 prof
Hi Martin, Yes it is amazing how bugs can just hide in the cracks for ever.
Please try the current development version 3.0.0.30 and report back. If 3.0.0.30 does not do this, try V3.0.0.29 and see if it does.
Which DisplayAs emulator are you using? Do the others do this?
I recently discovered a bug in V3, DisplayAs=ASCII (1st radio button) where following a null-chr(0), all manner of strange chars and strings appear on the terminal. V3.0.0.30 "fixes" in by falsing the char tp 0xFE.
Hello Simon,
Yes still wrong chars with 3.0.0.30.
I use the standard DisplayAs so it is ASCII. When I change it I get an error message (Access violation...), in 2.0.0.70.
Also I found that though I installed 3.0.0.30 into a different directory than 2.0.0.70, the later does not start anymore, some error with OLE registration. I deinstalled 3.0.0.30 and had to reinstall 2.0.0.70.
Hope that helps
Martin
Last edit: Martin Mensch 2016-07-04
V3.0.0.31 has fixed the nul problem that was causing strange/extraneous strings/chars in the terminal.
Can you test it and see if this problem still exists?