• State
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 42 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TL16C754C: Problem replacing ST16654 with TL16C754C - Data hanging

Everett Sykes1
Prodigy 60 points
Part Number: TL16C754C
Other Parts Discussed in Thread: AM3352

Hello,

INTRODUCTION:
My name is Everett Sykes. I'm a design engineer for Western Telematic, Inc. in Irvine CA. I’m using a custom board based on the Beaglebone Black with an AM3352 processor. We make a console server that has several serial ports, where each of these ports can be reached from several different inputs, such as any other serial port, Ethernet, Cell modem, etc. We were using the ST16654 QUARTs in Motorola bus mode. But we recently went to the TL16C754 QUARTs in Intel bus mode, because the ST16654 went end of life.

PROBLEM:
Since switching parts, I'm having the following problem:

I'm running a daisy-chain, loop back test where I connect several serial ports together, (alternating internal and external connections), and loop them back into each other. If I send a lorge block of data into this configuration, and then stop sending, the data should trickle through the system until all data comes back out the original port. This test works fine with the ST16654 QUARTs. But when I do the test with the TL16C754 QUARTs, the data seems to hang and never finish coming out. As if an interrupt got missed, or the handshaking got out of sequence. If, at that time, I send one more character into the input port, this seems to "kick start" everything and the data finishes coming out.

QUESTIONS:
1. Have you heard of this problem?
2. Is there someting I can do, in the code, that would kick start the data flow?

Please let me know.

Thank you for your time,
Everett Sykes

  • 0
    TI__Guru* 77791 points
    Everett Sykes1 said:
    1. Have you heard of this problem?

    The description seems like something that may have happened before (if you search through e2e) but hard to tell without more details. I don't think the C version of this device has what I'm thinking of though. 

    Everett Sykes1 said:
    2. Is there someting I can do, in the code, that would kick start the data flow?

    Can you provide me with what your register values are set to when you initialize the device?

    Can you also verify all registers during the stuck event?

    Can you also verify if the device data that you are receiving is correct? (After you kick start it). The device itself (all C versions) have an errata, but it results in a framing error not a stuck condition. 

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 60 points

    Hello Bobby,

    Regarding your first two questions:
    Reading the QUART registers is going to be a little tricky since there are multiple UARTs involved in the hangup, and I don't know which one is the problem. Also, I don't have a debugger connected to the unit at the time the data hangs. So I'll have to work on that one.

    Regarding your third question:
    Once the data is "kicked" through by sending another character in, the data seemed correct. I didn't see any corruption or missing characters.


    In the mean time, I have a couple more questions:

    INTRODUCTION:
    The main difference between the older ST16654 QUART and the newer TL16C754 QUART is the hardware interrupt circuit. The previous ST16654 part, when used in Motorola mode, has a single, active low, interrupt line on on each QUART (used for all 4 UARTs). The new TL16C754 part, which uses Intel mode only, has an active high interrupt for each UART (four lines on each QUART). We adjusted the circuit to accomodate this. And most of the time it works. We just, sometimes, get that hang when daisy chaining multiple ports together.

    QUESTIONS:
    1. It sounds like an interrupt might have been missed, so that data is waiting, but the Linux driver is never reading/writing because no new interrupt occurrs. Do you think it might restart the data if I somehow detect the hangup, and re-enable all interrupts for the UARTs involved? I'll try this while I'm waiting for your answer.
    2. Can you think of anything else I can do to kick start the data flow?


    Thank you for your time,
    Everett Sykes

  • 0 in reply to Everett Sykes1
    TI__Guru* 77791 points
    Everett Sykes1 said:
    Do you think it might restart the data if I somehow detect the hangup, and re-enable all interrupts for the UARTs involved? I'll try this while I'm waiting for your answer.

    Do you mean by writing to MCR[3]? My guess is this likely won't do anything but at the same time it wouldn't hurt to try. If there is an issue with this, it may be that there is some sort of issue related to the device entering the high impedance state on the IRx pins. 

    Everett Sykes1 said:
    2. Can you think of anything else I can do to kick start the data flow?

    I'm wondering if it's possible the interrupt is getting cleared at the same time it is being generated. This would be kind of tricky to figure out though, maybe if we can probe the interrupt pin that we think is getting generated and cleared and see a quick change of state from low to high and then back low. Maybe by setting the trigger to be under a certain bit period would help us catch this but based on what you're describing we don't know which channel is doing this. 

    Are you using any of the trigger level features? Maybe we can poll the RXRDY to check if data is still in one of the receive channels.

    -Bobby

    EDIT: please also note, I will be out of the office until Tuesday of next week. Sorry for any delays!