M68DEMO908GB60. - SCI Data Register Problem

[Tacky]

EDIT: accidentally hit enter instead of tab

Hey All:
First off sorry if this is in the wrong forum.
I am using M68DEMO908GB60.

I am simply trying to retrieve a data byte sent over serial cable via RxInterrupt.
I have my interrupt set up correctly - it triggers and runs through it properly.
I have checked the baud rates over many times - 19200 (have also tried 9600)

Here is the problem:
When I check (in memory in debug mode) when I send a byte it writes to the SCIxD correctly.
Only when I send the byte 0x7E (the most crucial byte of course...) the register then reads "0xFE".
I remember having a similar problem before when writing 0x00 and the register actually writing 0x80 (same problem as in the most significant bit is a 1 when it should be a 0) and it magically fixed itself.... (as the 0x00 byte was not important - I was able to continue with my program, the 0x7E byte, however, is needed to continue execution)


I've tried both SCI ports and multiple cables - same problem.

Wondering what may cause this?

Thanks in advance.

Message Edited by Tacky on 2007-08-03 04:14 PM

Added part number to subject.

Message Edited by NLFSJ on 2007-08-03 10:17 AM

[tonyp]

Maybe there is communication mismatch, like not using 8-N-1 on both sides.  One side could be 7 bits with 2  stop bits, or something similar?

[Tacky]

Thanks for the reply so quickly!

I have figured out my problem, despite the checks on the Baud Rates they still were the source...

I was calculating my baud rate based on a 18.97MHz Bus and not a 18.87MHz bus which caused all my headaches. Fixing this calculation seems to have solved my problem!

Thanks again.

[peg]

Hi Tacky,

These characters (all high/low) are the most difficult to recieve when there is a baudrate mismatch as the reciever will resynch to falling edges within a byte. This helps recieving when there is a baudrate mismatch but is less effective with less edges.

If you are not using an external oscillator/xtal here be sure to be correctly trimming the internal source to avoid this sort of problem.

See the following thread on this:

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=6884

Checking for framing errors (at least) in your recieve routine is easy and greatly aids in discovering these issues.

Message Edited by peg on 2007-08-04 08:43 AM