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.

System hangs when UART in CIR mode RXD line is kept low too long

On the DM8148 EVM, UART4’s RXD [Pin H25, PINCNTL251 ] is connected to the demodulated output of a IR receiver, through a combination of buffer drivers [IR Demod  -> Tri-state Buffer -> Schmitt Bufffe -> UART4_RXD]. The tri-state buffer’s output is pulled low [weak pull-down] and is used by software to turn off the IR remote function.  

Under normal operation, it is observed that the IR receiver drives the UART4 RXD line ‘high’ during periods of inactivity and ‘toggles’ [high-> low->high] it when there is IR activity. When we exercise the ‘IR remote off’ function in software, by tri-stating in-line buffer, the UART4 RXD is driven low by the Schmitt buffer, and this action locks up the entire system (software execution halts). 

The effect of continuously forcing the UART4 RXD line ‘low’ when UART4 is operating in CIR mode is causing system lock up. This behavior is consistent. What causes this behavior? Is it a HW or a SW issue (we are running the latest EZSDK 5.05.02.00)

The workaround is to force the UART4 RXD line ‘high’ [through a pull-up] when the in-line buffer is tri-stated by software but we would like to know the root cause of the problem.

  • Tiemen,

    UART4_RXD signal can be selected in 4 device pins: AD18, AE6, H25 and AG25. And you are using H25. As this UART4_RXD signal is input, make sure that you do not route/select this UART4_RXD signal to some of the other 3 pins: AD18, AE6 and AG26. The DM814x device does not support selecting input signals on more than one pin.

    Also, have a look in the below E2E thread, it looks similar:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/150487.aspx

    BR
    Pavel

  • Also, on DM814x EVM, UART1 is connected to the IR receiver. This is what we have:

    There are two UART interface (UART0 & UART1) available for DM814x/AM387x and one UART interface available for MSP430 on the EVM.UART0 on Base EVM is selected by enabling the signal UART0_OFF to LOW. UART0 is also routed to application boards UART interface through Board-Board connectors on the EVM. At a time either the UART interface (UART0) on Base EVM or application boards can be used.UART0 supports Baud-rate up to 3.6 Mbit/s.UART1 is connected to the IR receiver on the EVM. The IR Receiver is selected by enabling the signal IR_REMOTE_OFF to LOW.

    While you are using UART4 for IR on the EVM. Can this be the issue?

    BR
    Pavel

  • Pavel,

    Here is my customer's response (Remember they are using UART 4 in CIR mode):

    The UART4_RXD on our design is enabled on only one pin, H25, and all other pins that support UART4_RXD function [AD18,AE6 and AG25] are either unused or used as GPIO [Function #8].

    The original question was: "When we exercise the ‘IR remote off’ function in software, by tri-stating in-line buffer, the UART4 RXD is driven low by the Schmitt buffer, and this action locks up the entire system (software execution halts).  This causes the system to lock up." So the key issue we are trying to understand is why pulling the line LOW while the IR is set to OFF (i.e. tristated buffer) is locking up the system?

    Is this a SW issue (in which case we would like to know the fix) or a HW issue (in which case we would like to know that the pull-up resistor is the correct solution - see our original posting above)

    Kind regards

    T

  • Tiemen,

    What is the revision of your DM8148 EVM? I am confused, as I have rev.D EVM, and for IR is used UART1, not UART4. Also I do not see Schmitt buffer in the EVM schematics. See the pictures below;

    I see only IR Demod  -> Tri-state Buffer -> UART1_RXD.

    Best regards,
    Pavel

  • Tiemen,

    Please also note the R335 10K resistor, attached to the IR_REMOTE_OFF line. This resistor is marked with DNI (Do Not Include).

    Best regards,
    Pavel