16C752 Problem

hello!

i have a problem with the 16C752 double uart:

when i try to send a character by writing it directly into the THR, a different character (nearly always the same wrong character) gets sent. f.e. '10100101' instead of '00110000'

has anybody an idea?

additional info:

- fifo is disabled

- both uarts have the same behaviour

- receiving data works fine!!!

greets rom

Reply to
rom
Loading thread data ...

Probably the issue is with the programming of the chip, but I can't resist considering electrical signal issues:

xx01000011000xxx expected txd xx10111100111xxx inverted txd xxx01101001010xx actual rxd

Is it possible that your txd driver circuit is inverting its output and can't hold the inverted '1' voltage longer than one or two bit times? E.g., could you be sending a TTL logic level signal to a receiver expecting RS-232 signaling levels?

Could one end be set up for differential mode signaling?

Do the wrong characters change if you change the baud rate?

More info needed.

- Marsh

Reply to
Marsh Ray

hi marsh,

thanks for the quick answer and your ideas!

what do you mean with that exactly? (sorry, i'm not very experienced in hardware)

and here is some more info:

---------------------------

- i checked the programming of the chip again. i can't find any errors here. the parameters for br, db, sb, parity and flow control are set correctly. Interrupts and FIFO are disabled. (again: receiving data works fine!)

- the wrong character doesn't change, when i change the baudrate. and no matter what character i write, the sent character (today) is always '10110101'.

- i checked the LSR immediately before and after writing into THR and it seems ok. LSR is 0x60 before writing and 0x00 after writing.

- when i read the RHR after writing the THR (same address), i read the same wrong character!!!

- i tried to change the write-character in different ways maybe to see an interrelation between the character i write and the character that is send, but nothing changes. its always the same wrong f***ing character.

i will check the signaling levels tomorrow and i will write you again.

greets rom

Reply to
rom

rom escribió:

Where are you seeing the '10100101'? In the TX pin of the UART, with a logic analyzer or a scope? Behind the RS-232 driver, with a PC / terminal, or a comms analyzer? Do you get parity or framing errors?

Reply to
Ignacio G.T.

Sure!

A related standard to RS-232 is RS-422, with variations having some degree of compatibility.

formatting link

[]

Getting that kind of consistency at various baudrates strongly suggests the hardware is fine.

Still, it wouldn't hurt to try a different receiving device.

- Marsh

Reply to
Marsh Ray

hi there!

@ignacio

--------

i get the wrong signal through the whole line:

- at the TX of the UART

- at the Tin of the driver chip

- at the Tout of the driver chip

- at the TxD pin of the RS232 socket

- at the receiving PC program 'COMTerminal'

and when i make a shortcut from TxD to RxD at the RS232 socket, i can even

read back the wrong signal at the UART's RX (receiving works ;-)

all the signals have the correct levels. i measured with a scope.

i don't get any errors. after writing the character to send into the THR, the LSR-value is 0x00.

@marsh

------

i checked the signaling levels, they're ok (see the answer above).

what kind of different receiving device do you mean?

i don't use any kind of RS-422 devices or settings. why do you suggest that?

more info and a question:

------------------------- before the 16C752, we used the 16C552 on our board. i thought, that it's completely compatible regarding the SW and i don't have to change the sources of the driver-code. but now, as i have the sending problem, maybe there's something i didn't respect for the programming/configuration/initialization of the new chip.

is there something that differs to the old chip, that may cause that sending problem?

thanks a lot and greets rom

Reply to
rom

rom escribió:

[...]

Sure, I'll check it. I remember 16C752 having a problem when the FIFO is disabled, but I think it had to do with RX, not TX. It was documented in the data sheet.

Reply to
Ignacio G.T.

Ignacio G.T. escribió:

Er... sorry, what I meant was, obviously, _I'd_ check it, and not _I'll_ check it :-)

Reply to
Ignacio G.T.

hi there,

i started working on the problem again, 'cause the uart is still not able to send the correct character. (ok, i'm not able to get the uart working correctly ;)

today, i enabled the fifo, to see what's happening. with an enabled fifo, the sent (wrong) character changes! but unfortunately i can't see any interrelations between 'em. it seems, that the uart sends every content of its Tx-fifo except the expected character.

thanks for every idea!

rom

Reply to
rom

hello!

finally the UART works fine now :-) the reason for the problem was an incorrect access-handling of the CPLD.

thanks to all!

greets rom

Reply to
rom

If you want to post a followup via groups.google.com, ensure you quote enough for the article to make sense. Google is only an interface to Usenet; it's not Usenet itself. Don't assume your readers can, or ever will, see any previous articles. This applies whatever newsreader you are using.

More details at:

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.