• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 35 subscribers
  • Views 730 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TL16C550C: Auto Flow Control doesn't work

Andres Ortiz2
Prodigy 60 points
Part Number: TL16C550C


Hello,

I am trying to activate the auto-flow control feature in a TL16C550C UART (DIP40 version).

I follow what the datasheet indicates, activating bits 5 and 1 in the MCR register (0x22 value) after enabling FIFOs and Clearing interrupt enable register. However, I noticed that once the RX FIFO is full, the UART doesn't deactivate RTS signal, resulting in overrun. 

Does anyone know if anything additional needs to be done to activate the auto flow control?

Thank you,

  • 0
    TI__Guru* 75001 points

    Hey Andres,

    Are you able to verify that you are correctly writing the expected data into MCR? (Did you perform a read of MCR to verify the bits are properly set?)

    Are you accidentally setting bit 4 high?

    There shouldn't be any additional steps here.The only other register I could think of is IER bit 3 but that shouldn't affect the RTS signal (just the INT)....

    You could try setting the FCR bits 6 and 7 to be 1 to modify when the auto RTS should toggle.

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 60 points

    Hi Bobby,

    thank you for answering. Yes, I tried to read the MCR register after writing, but bit 5 is always read as 0. I also put FCR bits 6 and 7 to 1 but RTS does never toggle....

    Thank you,

    Andres.

  • 0 in reply to Andres Ortiz2
    TI__Guru* 75001 points

    Hey Andres,

    Are you able to confirm the byte you write into MCR is bit 5 and bit1 set? Since you are reading '0' for bit 5, I would double check your write is correct and the address is also correct. I would also make sure to double check the GPIOs of your processor is connected correctly with the device (like bit D5 and D6 aren't accidently swapped).

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 60 points

    Yes, the byte I am writing into MCR is 0x22 = 100010 but I read 10

    The GPIOs should be correctly connected  since all works OK (correct RX and TX) when I use standard (no automatic) flow control or no flow control. Charcters are correctly transmitted and received.

    Regards,

    Andres

  • 0 in reply to Andres Ortiz2
    TI__Guru* 75001 points

    Hey Andres,

    Are you still having issues enabling the AFE (Auto flow control)?

    If so, I can place an order for some samples and try to write 0x22h to MCR (or just walk through the same steps you do) and see if we get the same results.

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 60 points

    Hi Bobby,

    yes... I couldn't solve the issue. It seems like the AFE bit is not writable, since after writing 1 on that bit I always read it as 0.

    Thank you very much for your help. If you coould make come tests, I can try to reproduce them to compare the results.

    Regards,

    Andrés.

  • 0 in reply to Andres Ortiz2
    TI__Guru* 75001 points

    Hi Andres,

    Sorry for the radio silence, I've been out of the office. I just placed an order for some samples which will either arrive Friday or Monday. So I should be able to start trying to put together a board/test set up by next week.

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 60 points

    OK!. Thank you very much.

    Please, note that the versión I am using is TL16C550C - 40DIP packaged.

    Regards,

    Andrés.

  • 0 in reply to Andres Ortiz2
    Prodigy 60 points

    Hi Bobby,

    could you check the AFE feature?

    Regards,

  • 0 in reply to Andres Ortiz2
    TI__Guru* 75001 points

    Hey Andre,

    Sorry for the delay in response. I submitted the device to be soldered a few weeks ago and picked it up on Monday when I saw your message. I'll try to make time Friday to see if I can get this tested.

    -Bobby

  • 0 in reply to BOBBY
    TI__Guru* 75001 points

    Hey Andre,

    Sorry, I've been a bit loaded... We've recently picked up a new hire who I will be working with to help with trying to check this issue for you.

    I'll target for a follow up response end of next week.

    -Bobby

  • 0 in reply to Andres Ortiz2
    TI__Mastermind 26826 points

    Andrés,

    I created my own experimental setup to see if I could replicate your observations, but I was not able to produce any unexpected behavior.

    This setup includes a TL16C550C device that I’m interfacing, and I’m able to parallel read/write to the registers.

    Upon startup, I read each register to ensure that the values match what is expected after a RESET. See datasheet Table 2 for a verification on these expected values:

    Register

    Hex read value

    Bin read value

    Register 0 (Receiver Buffer)

    0x00

    0000 0000

    Register 1 (Interrupt Enable)

    0x00

    0000 0000

    Register 2 (Interrupt Identification)

    0x01

    0000 0001

    Register 3 (Line Control)

    0x00

    0000 0000

    Register 4 (Modem Control)

    0x00

    0000 0000

    Register 5 (Line Status)

    0x60

    0110 0000

    Register 6 (Modem Status)

    0xF0 (inputs)

    1111 0000

    Register 7 (Scratch)

    0xBD (irrelevant)

    1011 1101

    I wrote 0x22 to Register 4, as mentioned in your post. I was always able to read 0x22 from this register. This includes after multiple writes to the Transmitter Holding Register (i.e. transmitting data). After writing, I repeatedly observed:

    Register

    Hex read value

    Bin read value

    Register 0 (Receiver Buffer)

    0x00

    0000 0000

    Register 1 (Interrupt Enable)

    0x00

    0000 0000

    Register 2 (Interrupt Identification)

    0x01

    0000 0001

    Register 3 (Line Control)

    0x00

    0000 0000

    Register 4 (Modem Control)

    0x22

    0010 0010

    Register 5 (Line Status)

    0x60

    0110 0000

    Register 6 (Modem Status)

    0xF0 (inputs)

    1111 0000

    Register 7 (Scratch)

    0xBD (irrelevant)

    1011 1101

    Andres Ortiz2 said:

    the byte I am writing into MCR is 0x22 = 100010 but I read 10

    I tried to see if any other registers reflected this behavior by writing 0x22 to all registers. This was the result:

    Register

    Hex read value

    Bin read value

    Register 0 (Receiver Buffer)

    0x00

    0000 0000

    Register 1 (Interrupt Enable)

    0x02

    0000 0010

    Register 2 (Interrupt Identification)

    0x01 or 0x02†

    0000 0001 or 0000 0010

    Register 3 (Line Control)

    0x22

    0010 0010

    Register 4 (Modem Control)

    0x22

    0010 0010

    Register 5 (Line Status)

    0x22^

    0010 0010

    Register 6 (Modem Status)

    0xF2^

    1111 0010

    Register 7 (Scratch)

    0x22

    0010 0010

    †reads 0x02 once after writing 0x22 to Register 1
    ^this value changes after first read (bit 1 is cleared)

    Please note that MCR still reads 0x22 after these writes/reads. I did notice that reading the Interrupt Enable Register (Register 1) or the Interrupt Identification Register (Register 2) would return 0x02 (or 000000102, as you mentioned in your post). Is there any possibility that your test setup could be reading from IER 0x0001 or IIR 0x0010 rather than MCR 0x0101?

    Best,

    Danny