Weird WriteLn output

  • 1
  • 2
  • Page 1 of 2
Avra
Schreiberling
Avatar
Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002
Subject:

Weird WriteLn output

 · 
Posted: 13.10.2014 - 00:53  ·  #1
I would really appreciate another pair of eyes on this...

This code:
Code
  WriteLn(SerOut2, 'STARTED...');
  loop
    Toggle(SysLed);
    mDelay(500);
    WriteLn(SerOut2, 'ABCDEF'); // when I comment this line everything is as expected
    WriteLn(SerOut2, 'MyNumber=1234567890');
  endloop;


gives me weird output shown bellow on 2 identical MEGA64A boards with 5.04.73:
Code
STARTED...
ABCDEF
4567890
67890
er=123ABCDEF
MyNumber=1234567890
ABCDEF
MyNumber=1234567890
rABCDEF
12390
ABCDEF
Number=1234567890
123ABCDEF
mber=1234567890
34567ABCDEF
er=1234567890
567890
ABCDEF
r=1234567890
67890
eABCDEF
1234567890
7890
ber=ABCDEF
1234567890
67890
er=ABCDEF
34567890
67890
er=12ABCDEF
4567890
67890
er=123ABCDEF
MyNumber=1234567890
ABCDEF
MyNumber=1234567890
rABCDEF
yNumber=1234567890
=1ABCDEF
umber=1234567890
2345ABCDEF
mber=1234567890
34567ABCDEF
er=1234567890
567890
ABCDEF
MyNumber=1234567890
ABCDEF
=1234567890
67890
er

When I comment first WriteLn the output is as expected, so I do not suspect hardware. The minimal test project is attached.
Attachments
Filename: Test.zip
Filesize: 3.74 KB
Title:
Download counter: 29
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: Weird WriteLn output

 · 
Posted: 13.10.2014 - 13:44  ·  #2
Hello Avra,
I think your system needs the help of an exorzist :angry4:

I compiled both of your file versions and then compared the
generated ASM files. There was no difference. Sorry.

rolf
Harald_K
 
Avatar
 
Subject:

Re: Weird WriteLn output

 · 
Posted: 13.10.2014 - 20:02  ·  #3
maybe you should select 2 Stopbits instead of 1 ....

gives a little bit "space" between the bytes, so the USART will have more time for proper detect of the start bit.

and if you receive the data on a WindowsPC, it may depend on the used Win-Version what your COMPort will receive.
we ran an ATMega128-CPU with com-IF at 38400, for about 10 Years on a WinXP System, nothing strange happened.
now we changed the receiving PC to Win7 and a newer (faster) PC, sometimes some bytes are lost ....
Merlin
Administrator
Avatar
Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005
Subject:

Re: Weird WriteLn output

 · 
Posted: 15.10.2014 - 13:47  ·  #4
Hi Avra.

Just really to comment that I see the same thing on a PC with an XMEGA as well if two WriteLn statements are too close together. There never seems to be a problem in the other direction...
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: Weird WriteLn output

 · 
Posted: 15.10.2014 - 14:59  ·  #5
so two stopbits should help.
I always use 2 for security reasons.
These 1 stopbit is from teletype where every bit counts.

rolf
Avra
Schreiberling
Avatar
Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002
Subject:

Re: Weird WriteLn output

 · 
Posted: 16.10.2014 - 01:18  ·  #6
Thanks everyone for the feedback. I really, really do appreciate it.

I was really ripping my hair off with this serial communication problem, and I have spent countless debugging hours trying to isolate such a weird problem, and demonstration code is a result of cleaning my code until only the problem shows.

I have just tested with EvaBoard-485 and it also has weird output, so it's definitely not my hardware. Merlin has confirmed this behavior also with XMEGA.

I have always been using just 1 stop bit, and more then 90% of hundreds of serial devices I deal with was also using 1 stop bit never facing any communication problems of this kind. But to be open minded, I have tried on E-Lab EvaBoard-485 with both 1 and 2 stop bits. Result is the same weird behavior shown below. And yes, I have changed stop bits in my terminal software when it was needed for these tests.

Code attached.

Code
9600 8N1:

STARTED...
ABCDEF
890
MyNumber=1234567ABCDEF
MyNumber=1234567890
rABCDEF
=1234567890
7890
berABCDEF
MyNumber=1234567890
ABCDEF
=1234567890
7890
berABCDEF
MyNumber=1234567890
rABCDEF
=1234567890
7890
berABCDEF
MyNumber=1234567890
rABCDEF
MyNumber=1234567890
ABCDEF
MyNumber=1234567890
rABCDEF
MyNumber=1234567890
rABCDEF
MyNumber=1234567890
rABCDEF
MyNumber=1234567890
r


Code
9600 8N2:

STARTED...
ABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
berABCDEF
MyNumber=1234567890
rABCDEF
r890
ABCDEF
MyNumber=1234567890
rABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
berABCDEF
7MyNumber890
ABCDEF
MyNumber=1234567890
ABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
berABCDEF
MyNumber=1234567890
rABCDEF
=1234567890
7890
berABCDEF
=1234567890
7890
ber
Attachments
Filename: EvaBoard-485 bug demonstration.zip
Filesize: 1.41 KB
Title:
Information: demonstration code
Download counter: 28
Merlin
Administrator
Avatar
Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005
Subject:

Re: Weird WriteLn output

 · 
Posted: 16.10.2014 - 13:21  ·  #7
Hi Avra.

Out of curiosity, I guess you are using a serial to USB adapter on the PC (virtual comms port). Do you know if it is based an FTDI chip? Mine is.
Avra
Schreiberling
Avatar
Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002
Subject:

Re: Weird WriteLn output

 · 
Posted: 16.10.2014 - 13:55  ·  #8
Quote by Merlin

Out of curiosity, I guess you are using a serial to USB adapter on the PC (virtual comms port). Do you know if it is based an FTDI chip? Mine is.

Two MEGA64A boards already mentioned use FTDI FT230X, but EvaBoard-485 was directly connected to motherboard's serial port. So, it's not fault of a USB<>SERIAL convertor.

If you take a detailed look at output data, it looks like somehow pointer to serial data gets somehow corrupted when two WriteLn commands are issued one after another. I suspect that because the wrong output is not random. It is always something left over from previous data that was already out. So, no wrong bits, no new characters made by non matching communication settings on both sides. Wrong output is always made of characters being part of already made WriteLn output.

Maybe testing with some much older AvrCo compiler would produce correct behavior?
  • 1
  • 2
  • Page 1 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 16 · Cache Hits: 15   127   142 · Page-Gen-Time: 0.033094s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI