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

On Nov 5, 11:14=A0am, "rom" <r.lindent...@e-wilhelm-gmbh.de> wrote:
> f.e. '10100101' instead of '00110000'

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

hi marsh,

thanks for the quick answer and your ideas!

>Could one end be set up for differential mode signaling?
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

rom escribi�:
> 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!!!

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?

On Nov 6, 9:51 am, "rom" <r.lindent...@e-wilhelm-gmbh.de> wrote:
> hi marsh,
>
> thanks for the quick answer and your ideas!

Sure!

> >Could one end be set up for differential mode signaling?
>
> what do you mean with that exactly? (sorry, i'm not very experienced in
> hardware)

A related standard to RS-232 is RS-422, with variations having some
degree
of compatibility.
http://en.wikipedia.org/wiki/RS-422

> - 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 will check the signaling levels tomorrow and i will write you again.

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

hi there!

@ignacio
--------
>Where are you seeing the '10100101'? ...

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 ;-)

>with a logic analyzer or a scope?...
all the signals have the correct levels. i measured with a scope.

>Do you get parity or framing errors?
i don't get any errors. after writing the character to send into the THR,
the LSR-value is 0x00.


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

>Still, it wouldn't hurt to try a different receiving device.
what kind of different receiving device do you mean?

>Could one end be set up for differential mode signaling?
>...RS-422...
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

rom escribi�:
> hi there!

[...]

> 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?

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.

Ignacio G.T. escribi�:
> rom escribi�:
>> hi there!
> 
> [...]
> 
>> 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?
> 
> 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.

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

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

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