This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TL16C752C: Compatibility of TL16C752C, TL16C752D and TL16C752B

Part Number: TL16C752C
Other Parts Discussed in Thread: TL16C752D

Hello,

I have an old design using TL16C752B. The device is connected to a Ti DSP to provide two additional  uarts both of which operate as 115k2 data pumps (i.e. no flow control) with interrupts.

Using the obsoleted 'B' part my design works perfectly.

If I replace the 'B' part on a working board with either a 'C' or a 'D' part then no uart traffic is generated.

I'm yet to debug the code running on the DSP, but by analysing the datasheets I cannot see any reason why the 'C' or 'D' parts wouldn't work. I'm running all the parts from a 3.3V supply using a 24 MHz external clock.

1) Do you have any idea why the UART might not work (it could be an identification routine in the code, but as there is no device id I can't see this)

2) In the described mode what is the difference between the 'C' and 'D' variants (other than the obvious package variant and temperature variant, and different UART speed vs supply voltage differences)

3) I found this forum response 'Difference between TL16C752D and TL16C752B' which basically indicates that what I'm tyring to do should just work.

Thanks,

Paul

  • Hello Paul

    I would like to have more information regarding this issue. Can you send me a diagram connection, configuration of UART (prescaler, divisor, stop bits, parity, etc), kind of clock (signal generator, xtal, crystal oscillator)?

    1 - I need more information about the issue to have an idea.

    2.- We have an errata regarding to the stop bit in version C, this issue was fixed in our version D and other errors that we found in C version. In terms of Voltage, and speed are the same. In terms of temperature, we have two versions, normal version and automotive version.

    Please, send me the information and also extra comments regarding to your issue.

    Regards
    Francisco
  • Hi Francisco,

    Sorry for the Delay I've been away.

    I have an update for this problem.

    Using the obsolete 'B' version my software works perfectly, using the current 'D' version it does not.

    I now have this scenario:

    I write several bytes to the UARTA fifo and measure the TXA and TXB serial output lines. The data I wrote into the UARTA fifo is transmitted on both TXA and TXB. I can measure the CSA and IOW lines are driven correctly by my application and that UARTB is never written to.

    Next I write several bytes to the UARTB fifo and measure the TXA and TXB serial output lines. The data I wrote into the UARTA fifo is transmitted on both TXA and TXB. I can measure the CSB and IOW lines are driven correctly by my application and that UARTA is never written to.

    Do you have any ideas about what could cause this problem?

    Thanks

    Paul

  • Hello Paul

    This is not clear to me yet, I need more information. If you want to send data from TXA, you have to write into UART A, if you want to send data from UART B you have to write into UART B. When you want to write into a Channel, you have to use CSX for each channel. Are you using an special configuration? Can you send me the work mode that you are using? Do you have external connection with both channels? Please, send more details about your app, configuration and work mode.

    Regards
    Francisco
  • Hi Francisco,

    I'm not sure why this isn't clear to you yet, my last description is quite clear.

    For future readers of this forum, I've solved this problem.

    There is a concurrent function in the special functions register of the TL16C752D variant which results in this behaviour. While I'm never intentionally setting this bit, it is set after my initialisation.

  • Hi Paul

    Is great to see that this one was fixed! I recommend you that in further posts describe with more detail your issues because this is an special feature of these devices. This description is not a normal behavior of this UART, that's why wasn't clear to me.
    Thank you so much for clarify.
    Regards
    Francisco