TL16C752D: Receive Interrupt clear way when Receive FIFO becomes empty

Hello Ninomiya-san,

We are checking into this and will get back to you early next week.

Regards,

Max

Hi Max-san,

I look forward to your check results.
I received additional information from the customer as attached below.
Thank you.

Best Regards,

Koshi NinomiyaTL16C752D.xlsx

Hi Ninomiya-san,

Thanks for sharing the extra information. The program flow described here looks good. It appears that the interrupt is active because the device has perceived an RX Timeout. This is indicated by the value in IIR: 0xCC. This is also reflected in LSR[7] being set to show Error in RX FIFO. This interrupt is cleared by reading from RHR. It is strange to see that when this read is done, the interrupt does not clear.

Could you please share the contents of the register after RHR is read while RX FIFO is already empty?

I see at the start of the code diagram you shared, the program checks for RX Timeout interrupts. How does this section of code handle this interrupt? Is the section used in the tests you describe?

I would not expect a delay (especially as long as 10ms) to allow for the interrupt to auto-clear. Is the device possibly being reset during this time? Fluctuations in supply or controller watchdog timeout?

Could you please specify the test difference between Waveform 1 and Waveform 2? Reading RHR using software does not clear the interrupt – but reading RHR through UART controller does clear interrupt?

Regards,

Eric

Hi Eric-san,

Could you please share the contents of the register after RHR is read while RX FIFO is already empty?
 A: The contents of the register after RHR is read are as contents which were written in the excel file at previous post.
        IER         0x05
        IIR          0xCC
        LCR       0x1F
        MCR      0x0B
        LSR        0x60
        MSR      0xB0
        SPR       0x00
     And the contents of the RHR register is "0x06" at this time.
     It seems that the original communication data 0x06 0x0D 0x0A (ACK + line feed code) was correctly received, but the interrupt was not released at 0x06 regardless of how many times the RHR register was read.

I see at the start of the code diagram you shared, the program checks for RX Timeout interrupts. How does this section of code handle this interrupt? Is the section used in the tests you describe?
  A: The method of interrupt processing when an RX timeout is detected is generally as follows (the processing is the same when an RHR interrupt is detected)
     　　　   for loop(RX FIFO size){
　　　　　   Read LSR
　　　　　　If(BIT0 of LSR is 0){
                        Read RHR・・・・①
                         break;
                      }
                     Read RHR・・・・②
                  }

      Waveform 1 is,
      Stop at a debugger breakpoint before executing the process in interrupt processing.
      This is the waveform when the processing in step ① is executed in step execution.

      <Additional information>
      - In case of TL16C752B,  step ① was not written, then when all receive data was read, it seemed that receive interrupt was cleared.
      - In case of TL16C752D,  step ① was added to aim this issue. In the situation where the interrupt is not cleared, step ① is executed to exit the interrupt processing, and the interrupt is repeated.

I would not expect a delay (especially as long as 10ms) to allow for the interrupt to auto-clear. Is the device possibly being reset during this time? Fluctuations in supply or controller watchdog timeout?
  A: Regarding the 10ms delay, it worked when they tested it with a delay in the task's transmission process before it was initially determined whether it was a transmission interrupt or a reception interrupt. It is recognized that there is no power fluctuation or controller reset during this time, but there may have been a change in the access timing to the controller register or the order due to the shift of the transmit FIFO / empty interrupt timing.

Could you please specify the test difference between Waveform 1 and Waveform 2? Reading RHR using software does not clear the interrupt – but reading RHR through UART controller does clear interrupt?
  A: Waveform 1 is the waveform when the process of step ① described above is executed by software.
      They read RHR many times by repeating the process of interrupt processing.
      But IRQ is not cleared.

     Waveform 2 using the CPU's ICE debugger, and this is the waveform when the address of the UART controller is read
     (Accessed by memory mapped I / O method).
    In this case, the IRQ is cleared.

Thank you.

Best Regards,

Koshi Ninomiya

Hi Ninomiya-san,

Thanks for your patience and clarifications, this is an odd problem. 

1. I misunderstood the timing of the register values. Thank you for your explanation. To confirm, the states listed are present after step (2) is performed?

2. When using TL16C752B vs.TL16C752D, running the same code without step (1) results with the issue in TL16C752D and not TL16C752B. Is this correct?

3. It is strange to hear that the device behaves differently when accessed directly by the CPU's ICE debugger. Would there be a way to confirm that the read process for both is the same? Perhaps the debugger has more steps prior that prompts the different behavior.

4. When repeatedly reading RHR, you are continuing to receive the same value "0x06" even though the FIFO appears empty. Is this correct?

5. From what pin is IRQ being measured from? Is this the state of the RXRDY pin? If not, does RXRDY remain LOW after reading RHR with an empty FIFO?

Regards,

Eric

Hi Eric-san,

1. Yes, after step (2) is performed, read the register values at next step (1).

2. Yes.

3. The reading process of the ICE debugger has not been elucidated. They also want to know where the reading of the ICE debugger is different, so they want to investigate in parallel.

4. Sorry, this information was not certain.
    When source-level debugging was performed on the execution part of Step (1) with the ICE debugger, the contents of the variables only looked like that.
    Actually, the contents of the RHR register may not be correctly reflected, or may depend on the state of the stack memory.
    When they checked it again, the contents of the variable looked like 0x00.
    When reading with the ICE debugger, the value that can be read at the same time when the interrupt is released is also 0x00.

5. The last time the IRQ of the waveform did not look directly at the pins of the TL16C752D.
    The TL16C752D INTA output entered the FPGA, and the IRQ output (low active) via the FPGA was input to the CPU because it was easier to pinch the clip, so they saw it there.

    This time, they checked the state of INTA pin and RXRDYA pin of TL16C752D, and attach the waveform.
     - Attached file Fig1 is when RX FIFO interrupt occurs. INTA and RXRDYA are active at the same time.

     - Fig2 shows the RHR read in the previous step (2) (it is not empty, but actually contains received data).
       RXRDYA is cleared at this timing. INTA remains High.

     - Fig3 shows that the address including RHR is read by ICE debugger.
       When read by the ICE debugger, INTA goes low.

Thank you.

Best Regards,

Koshi Ninomiya

Hi Eric-san,

I look forward to your reply to 1 to 5.

There are additional questions from the customer as follows,

Q6:
After the signal is received on chA and / RXRDYA and INTA are asserted, reading RHR deasserts / RXRDYA and INTA.
The timing is quite different between the de-asserted  /RXRDYA  and the de-asserted INTA in case of the TL16C752D.
  --> Please check attach actual measurement waveform below
  TL16C752D Waveforms at RHR Read.xlsx
Are the de-assertion conditions for the above two signals common in the TL16C752D?
Or is it logically different inside of the TL16C752D?
If they are logically different, please tell us about each deassertion condition.

Q7: 
Looking at Figure 2. General Read Timing of datasheet of TL16C752D, it shows the / IOR condition when / CS is active and the / CS condition when / IOR is active.
As a read operation, if / CS becomes active first, / IOR is asserted when t6s is satisfied, and / CS is deasserted first when t7w is satisfied, there will be a problem with the operation in the TL16C752D, will not there?

Thank you.

Best Regards,

Koshi Ninomiya

Hey Koshi-san,

Eric is currently out of the office so I will be taking this e2e post.

"Q6:
After the signal is received on chA and / RXRDYA and INTA are asserted, reading RHR deasserts / RXRDYA and INTA.
The timing is quite different between the de-asserted  /RXRDYA  and the de-asserted INTA in case of the TL16C752D.
  --> Please check attach actual measurement waveform below
  TL16C752D Waveforms at RHR Read.xlsx
Are the de-assertion conditions for the above two signals common in the TL16C752D?
Or is it logically different inside of the TL16C752D?
If they are logically different, please tell us about each deassertion condition."

Deasserting the RXRDY should occur when you read RHR and empty it in DMA1 mode. The other case for RXRDY to deassert is when an error on the RX line has occured.

INT can deassert depending on what INTs you have enabled. In your original post, it looked like reading IIR indicated a RX timeout occurred. Assuming other interrupts have not occured then I would expect the INT to deassert. (which seems like it isn't in your case).

deassertion timing can differ from INT and RXRDY if the two have different assertion triggers. This device is mainly digital logic so in some form of AND/OR-muxes INT could also take some additional time to change logic state because it goes through more logic gates.

I would probably need to play around a bit with our internal EVM of this device to see if I can get the INT and RXRDY to deassert at the same time or if it actually occurs out of sync like your waveform.

"Q7: 
Looking at Figure 2. General Read Timing of datasheet of TL16C752D, it shows the / IOR condition when / CS is active and the / CS condition when / IOR is active.
As a read operation, if / CS becomes active first, / IOR is asserted when t6s is satisfied, and / CS is deasserted first when t7w is satisfied, there will be a problem with the operation in the TL16C752D, will not there?"

Internally the device uses an "AND" logic to see if both CS and IOR are low before implementing the read. Which ever goes low first or high later should not matter (to read all you need is both lines low). You can even hold CSA low the entire time and instead just toggle IOR/IOW if you wanted to focus only on channel A.

----------------------------------

I would like to see if I can recreate the customer's issue on the bench.

Can you provide me with the customer's:

• Clock speed:
• Baudrate:
• Vcc:
• Register write flow (Writes to IER, then LCR, then ect...)
• High level procedure on how they check  when they need to read RHR

for loop(RX FIFO size){
　　　　　   Read LSR
　　　　　　If(BIT0 of LSR is 0){
                        Read RHR・・・・①
                         break;
                      }
                     Read RHR・・・・②
                  }

This is what you posted previously. I would like to know if they look for an INT/RXRDYA/or solely look at LSR

Thanks,

-Bobby

Hi Bobby-san,

"Q6:
 > deassertion timing can differ from INT and RXRDY if the two have different assertion triggers. This device is mainly digital logic so in some form of AND/OR-muxes INT could also take some additional time to change logic state because it goes through more logic gates

  --> Is there any possibility that only RXRDY is deasserted under the condition that both INT and RXRDY should be deasserted?

the customer's:

• Clock speed: 14.7456MHz
• Baudrate: 19200bps, Data 8bit, Parity even, Stop-bit 2bit, Flow-cont none
• Vcc: 3.3V
• Register write flow (Writes to IER, then LCR, then ect...)
  
     *Regarding the write flow to the register, when receiving a FIFO where a problem occurs, the data is read only and is not written. However, the write flow in the initial processing at startup is as follows.
  

  　Write IER:0x00

  　Write FCR:0x00

  　Write MCR:0x00

  　

  　Write MCR:0x00

  　Write IER:0x00

  　Read LCR

  　Write LCR: Take OR between LCR Read result and 0x80 (set LCR[7]=1)

  　Write DLL:0x30

  　Write DLH:0x00

  　Read LCR

  　Write LCR: Take AND between LCR Read result and 0x7F (set LCR[7]=0)

  　Write FCR:0xFF

  　Write LCR:0x1F

  　Write MCR:0x08

  　Write IER:0x05

   

  　Read MCR

  　Write MCR: Take OR between MCR Read result and 0x03 (write 0x0B)

  *By the write flow above, the write processing at the time of startup is completed.
  *The register values at the time of processing up to this point are as follows when read by the debugger,
   
  

  RHR:0x00

  IER:0x05

  IIR:0xC1

  LCR:0x1F

  MCR:0x0B

  LSR:0x60

  MSR:0xB0

  SPR:0x00

   
  
  
• High level procedure on how they check  when they need to read RHR
  
  Regarding the process of reading the received data from the RHR,
  Interrupt processing is started from the interrupt signal linked to INTA,
  Follow the steps below to access RHR.
  #1. Lead the IIR
  #2. If the value of BIT0-3 of IIR is 0x4 or 0xC, start "Reception processing"
  #3. This "reception processing" is the following processing that we contacted before.
  That is,
  
  for loop(RX FIFO size){
            Read LSR
            If(BIT0 of LSR is 0){
                                 Read RHR・・・・①
                                    break;
                                           }
                            Read RHR・・・・②
                                     }
  

  Supplement.
   - RHR is read by processing of ② for the number of received bytes in the for loop.
   - If all received data is read, RXRDY is canceled at the processing of ②
   - If the received data becomes empty, after execute the processing in ①, exit the loop to complete the reception interrupt processing
   - In our situation, since INTA is not released and the register of IIR is the value of 0xCC, after that, repeat steps #1 to #3 endlessly.

  Thank you.

  Best Regards,

  Koshi Ninomiya

Hey Koshi-san,

"Is there any possibility that only RXRDY is deasserted under the condition that both INT and RXRDY should be deasserted?"

No, there is not a way to program/set registers to make RXRDY only deassert when both are deasserted. Externally, you could feed the two signals into an AND gate but not from the software point of view.

As for your additional information, I'll see if I can put together code tomorrow to try to copy what you are seeing. I'll post an update if I run into any issues on this before I leave tomorrow.

Thanks,

-Bobby

Hey Koshi-san,

I currently have the initialization code set up but I need additional information.

what data are you sending? Ex.(0xAA,0xAV, 0x1F.....byte 60) I assume you are sending 60 bytes consecutively.

I see that you have the loopback mode enabled in the device, are you writing to THR through TXA?Or do you have a separate processor sending data into RXA?

Thanks,

-Bobby

Hi Bobby-san,

According to the customer,
There is another processor that sends data to RXA.

If a reception interrupt occurs even for one byte, the phenomenon will occur.
In the test, from communication software connected with a separate cable, for example, only one character such as "1" or "a" (ASCII code 0x31 or 0x61) is sent.

Even in the operation of the actual application, the data received continuously at one time is less than 60 bytes.
0x06 0x0D 0x0A (ACK, CR, LF) etc. are received.

Regarding THA,
In the test, if data is received by RXA before writing data to the THR even once, a phenomenon occurs, so nothing is being transmitted.
(A real application sends 59 bytes of data every 10 minutes.)

Thank you.

Best Regards,

Koshi Ninomiya