strange UART junk characters

[irob]

Hey all, I'm troubleshooting an odd problem.  I have a DEMO9S08QG8 board, on which I've programmed the SCI for UART functions.  The demo board has an RS232 transceiver.  I'm using Realterm to talk to this board.  That's all working fine, except for a few stray "junk" characters that my serial port is receiving from the ether.

See the screenshot for my Realterm app interface.  A simple EEPROM controller.  Right under the "Enter memory address", I've entered a "23".  Notice the block between the 2 and 3?  This appears to be some other ASCII escape code, perhaps a 0xDF or 0xFE.  Similar thing after the line "Enter data".

Also, notice that the CTS and DCD and DSR lights are on.  The demo board seems to have RTS and CTS wired for hardware flow control (see schematic screenshot).  I have attempted the "None" option as well as other hardware flow control options in Realterm.  None seem to quiet the junk.

On a whime, I loaded this firmware into a different MC9S08QG8 target board, which has an RX/TX only transceiver.  I see none of these junk characters.

[PeterHouse]

The CTS, DCD, and DSTR lines should not have any effect on the noise.  I would bet the noise is timing related.  Do you have a 'scope?  If so, use it to measure the bit time and make sure you crystal and dividers are correct.  You should probably start by calculating your timing error as very few crystals and divisors work out to a perfect serial timebase.  If your error calculates to more than 3% then this is likely your problem.

I would also bet that the PC is correct but if you havce a 'scope you should check it also just to make sure.

Good Luck,

Peter House

[irob]

Good thoughts, Peter.  To compensate the timing incompatibilities, I'm already instantiating the ICS TRIM register this way:

volatile byte NV_FTRIM_INIT @0x0000FFAE;volatile byte NV_ICSTRM_INIT @0x0000FFAF; // instantiate the nonvolatile ICS Trim Register...  if (NV_ICSTRM_INIT != 0xff)  {    ICSTRM = NV_ICSTRM_INIT;  // load trim value if location not blank  }

[peg]

Hello,

I would not think this is a baud rate mismatch here.

Baud rate mismatch usually results in wrong characters, not extra ones. (escpecially if most are correct)

You have to be a long way out to generate extra bytes and then you won't be getting much that is recognisable.

The CTS and RTS IS wired but won't actually do anything unless YOU programme it in yourself.

DCD and DSR are on because DTR is on and they are linked back on the board.

Are the characters on screen an echoed back representation of what you typed in?

[Lundin]

As crappy as the UART technology is (sync:ed every 10th byte), it doesn't take much to generate an extra byte. All you need is a negative flank. If the receiver clocks in the stop bit while the transmitter is still sending the last data bit, the remains of the data bit could be regarded as the start of a new byte, which would get the value 0xFF or some such.

First thing I would check is whether the board is running on a flakey internal oscillator or if it is using an external crystal/osc. Internal oscillators are typically not accurate enough for serial data transmission.

Also check the signal with a scope so you are sure there's no EMI glitches on it.

[peg]

Well, look who got out of the bed on the wrong side this morning!

Not sure which crappy UART you are describing but the crap included in S08's sync's up to every negative edge. Now some bytes don't have additional edges but most do.

There is the usual 16x sampling and two out of three voting on the bit determination. Proper use of the noise and framing error flags will identify all but the worst of problems

The flaky internal oscillator is about an order of magnitude better than what is required for reliable SCI communications as evidenced by the millions of serial links running flawlessly on them.

Sure wave a scope over the connection but I doubt that this is the issue here.

Having Realterm display the hex value of every byte can shed light on what may be happening here. Looking at the binary value recieved compared to what is expected can often help. Such as 1 bit differences etc.

[irob]

Hey, Peg.  Of course, hex output!  I've switched Realterm to Hex + Ansi to inspect what these characters are.  It appears to be a regular set of four nulls after each character that I enter (only after my RX input, not the TX traffic from the target).  Here's a screen shot (#3).

The 4th screenshot is ansi only, so that you can discern what the ascii output really is.

[bigmac]

Hello irob,

While I would not have expected the null characters to create any problem, clearly they should not be there.  You might investigate what is causing their transmission within your code, an eliminate them just in case.

Since you have selected ANSI characters, rather than ASCII characters, it may be possible that the terminal program is interpreting them as an invalid ANSI character.  You might also try an alternative terminal program (e.g. Hyperterminal) to see whether the spurious characters are still displayed.

Regards,

Mac

[peg]

Hello Mac,

The reason for using a terminal programme like Realterm over, say Hyperterminal, is that it will display correctly all possible 256 codes. Hyperterminal fails miserably at this. In ASCII mode only CR and LF actually do something other than write to the screen.

[peg]

Hi Rob,

Did you find your problem yet?

Actually, with Realterm, I prefer to leave it in ASCII mode and use the Terminal_Ctrl+Hex font.

This gives you normal spaced ascii and control codes that occupy only one character space and hex values for the top page.

[irob]

Peg, the only problem with the ASCII display mode is that the LFs and CRs get displayed as font characters, which I think are distracting if you're using the terminal for diagnostic app purposes.  See attached for my app in this mode.  Interestingly, you see more noticably the nulls at the end.

That's why I prefer the ANSI mode, since it apparently hides the LF and CR control characters.

[peg]

Hi Rob,

Yes, well we are talking personal preferences here.

I think that in ANSI mode you will find that other codes are interpreted with even more chaos.

ANSI has lots of cursor manipulation codes for instance.

Still not sorted your problem yet?

It seems to me it is with your transmit code.

[irob · Accepted solution]

Peg, I did finally find the culprit.  You were right, by the way.  Here was my TX code:

void SendString(byte * s){  SCIC2_TE = 1;     // read, enable Tx  while (*s != 0)  {    __RESET_WATCHDOG(); // feeds the dog    while(!SCIS1_TDRE)    {      __RESET_WATCHDOG(); // feeds the dog    };    SCID = *s;    s++;  }  while(!SCIS1_TC)  {    __RESET_WATCHDOG(); // feeds the dog  };  SCIC2_TE = 0;         // disable Tx} // end SendString()

That final disable of the transmitter was causing the spurious nulls.  Don't know why, so I removed that line and left the transmitter on the whole time.  Works fine.

[bigmac]

Hello irob,

The explanation would appear to be quite simple ...

Whenever you disabled the transmitter, the TxD pin would revert to a GPIO, and the state then outputted would depend on the initialisation settings for the pin.  Presumably you had an output low state, which would have been interpreted as a start bit, followed by all zeros.  Even though there would have been no stop bit, and a framing error would result, the terminal program still saw this as a null byte.

This situation could also have represented a break sequence.  I wonder how the terminal program does respond to an incoming break in a non-debug mode?

I suspect this would not have occurred had you initialised the pin to a Tx idle (output high) state.

Regards,

Mac

[peg]

Hi Rob

Glad you fixed it!

I was going to mention something like that earlier.

I often put untested boards into a "bed of nails" test jig, programme them in the jig and then test them.

Before they are programmed you often get strings of NULL's on a connected terminal.

[PeterHouse]

Peg - you are right - I was thinking garbage character and not extra garbage characters.

A 'scope picture is worth 1,000 DVM readings . . .

Peter

[irob]

Good thoughts, Peg.  That was my thinking too, that because the bulk of the characters are correct, this likely wasn't a BAUD problem.

The numerical digits on that screenshot are a software echo in my Receive function.  The "extra" characters should not be.  Realterm has its own echo feature which will loop back received data.  I have that feature turned off.

The real puzzler is that this same load of firmware, running on a different QG8 target board that I designed, runs fine with none of these "extras".  It's rock solid.  Same set of RS232 cabling, Realterm session, power supply, etc.

It's as if there's something on the fritz with the Demo board, doesn't it?  Although I can't imagine what.