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.

TL16C752D: UART ISR Problem with Large Block Data Transmission

Part Number: TL16C752D

Not sure if this is going to Bobby. If so, hi Bobby long time no talk to.

Anyway, I am now trying to use INTA for my TX/RX ISR. Everything is working well for the 40 byte command/response data transferred between the two processors.

The problem I am having is with the large block data (292 byte response packet). This would require four 60 byte blocks and one 52 byte block left over.

When I set the 485LG bit and start transmitting the 292 byte packet, I can't get the streaming of the data to work.

My question is this:

Should the THR Space Available Interrupt continue to be set?

I'm using the following setup when getting ready to send 292 bytes:

  • TLR value set to 0x0F (60 Byte Tx FIFO)
  • 485LG bit set to 1
  • 485EN bit set to 1
  • RCVEN bit set to 1
  • RHR Interrupt Enabled
  • THR Interrupt Enabled
  • IRQA Enabled

Inside the ISR I perform the following:

  • Read the IIR
  • A switch statement acts on the active interrupt
  • RHR Interrupt reads the request packet and generates a response packet( in this case 292 bytes)
  • Once the response packet is generated, the THR interrupt is enabled
  • Inside the THR case, transmit a byte and re enable the THR Interrupt until finished with the 292 bytes
  • Once finished, disable the THR Interrupt
  • Receive the next request and generate the response again.

Do I need to actually break the transmission into four 60 byte blocks and the final 52 byte block?

When getting ready for the 52 byte block, do I need to set the 485LG bit to 0?

Thank you for the help,

Reif Heck

  • Hey Reif,


    "When I set the 485LG bit and start transmitting the 292 byte packet, I can't get the streaming of the data to work."
    Are you able to elaborate on what is happening? Where does the failure start? Are you able to see data appear on the serial lines? Are you getting stuck after the first 60 bytes?

    "Should the THR Space Available Interrupt continue to be set?"
    Because of how you initialized the device, the TLR register will set the trigger points at which point the THR empty should toggle. The TLR register essentially is like the FCR's trigger level but it utilizes 4 bits instead of 2 bits. The granularity is 4 meaning you could actually change the TLR to be lets say 52 by setting the TLR to 13 (13*4=52) in hex this would be 0x0D. (you could do this on your last packet of data).

    "Inside the THR case, transmit a byte and re enable the THR Interrupt until finished with the 292 bytes
    Once finished, disable the THR Interrupt
    Receive the next request and generate the response again."
    Because you have TLR set, THR INT will not trigger until you go above the trigger level (in your case 60 bytes). So for the last 52 bytes you should set the TLR to 0x0D if you want to trigger an INT when you fill the FIFO with 52 Bytes of data.

    "When getting ready for the 52 byte block, do I need to set the 485LG bit to 0?"
    You shouldn't have to but I am not 100% sure.

    Thanks,
    -Bobby

  • Hi Bobby,

    Good to hear from you again! I thought it would be you ;~)

    I ended up having to use INTA connected to an available interrupt pin on my micro.

    It is actually working quite well with the short packet (39 bytes). I'm only seeing an issue with the 292 byte packets.

    I can send quite a few 292 byte packets(mainly 36 packets sometimes 72) without having to do anything. I have a function that calculates the number of 60 byte blocks to send and calculates the bytes left over (in this case 52 bytes).

    The problem is happening on the last packet that is being transmitted. The transmission gets cut off and sends the last 42 bytes of the packet.

    The steps i am using in the ISR are as follows:
    case RX TIMEOUT:
    Receive and Verify Request Packet
    Create Response Packet and get Response length
    Disable RHR Interrupt
    Enable THR Interrupt
    case TX SPACE AVAILABLE:
    Transmit byte
    Check to see if Index == Response Length
    If not, re-enable the THR Interrupt
    if it is, disable THR Interrupt and re-enable the RHR Interrupt

    I'm not sure setting 485LG = 0 or 1 is having any effect.

    What has me confused is how to tell if I have to send the last 52 bytes.

    thank you Bobby,
    Reif
  • Hey Reif,

    "The problem is happening on the last packet that is being transmitted. The transmission gets cut off and sends the last 42 bytes of the packet."
    Are you saying that you are actually losing the first 10 bytes of data? (they aren't getting through the serial lines (TXA))?

    "Transmit byte
    Check to see if Index == Response Length
    If not, re-enable the THR Interrupt
    if it is, disable THR Interrupt and re-enable the RHR Interrupt"
    This sounds like you are not actually using the TLR because you are disabling the THR int and re-enabling it

    I'm wondering if your problem is that you are trying to clock in data too quickly. What is the time difference between you writing data into THR? (also what is your clock speed and baud rate)

    -Bobby
  • Hi Bobby,

    I must apologize for restarting this thread.

    My issue has nothing to do with the ISR at all.

    The issue is the fact that in my main work loop I am reading an ADC sample every 350 uSecs and writing it into a ring buffer.

    Whenever I get a request for the large packet data in the ISR, i verify the request packet and then generate the large packet response. This includes grabbing the ADC data from the ring buffer. If I tunr of the reading of the ring buffer, everything works as advertised and no issue with the large packet transmission.

    So I was looking in the wrong spot. My logic analyzer showed me right where the problem is.

    Anyway sorry for wasting your time.

    Thanks for looking at it anyway.

    We can close this.

    Thank you Bobby,
    Reif