• Resolved

PROCESSOR-SDK-AM335X: UART looback issue

Expert 1810 points

Replies: 11

Views: 86

Part Number: PROCESSOR-SDK-AM335X

Hi,

I am using SKAM335x board and TI SDK RTOS on windows host PC.

I have enabled uart0 looback for testing. I am sending data and same data I am receiving. When I do step in while debugging it is receiving a data properly but if I run the program without any breakpoint or step in then uart0 is not receiving data correctly. 

I gave delay also between transmit and uart but then also it is not working.

Another thing is that, if I have enabled the loopback then why it is printing data on terminal whatever I am transmitting. This problem is coming while running the code completely not in step in.

Please suggest any solution to this problem.

Regards,

Gaurav

  • Hi Guarav,

    Are you using a UART example provided with PRSDK?

    What version of PRSDK are you using?

    Have you made modifications to the code?

    I assume this is an internal loopback (configured w/ switch below), not an external loopback?

    uint32_t loopback;
    /**< flag to indicate in loopback mode */

    Regards,
    Frank

  • In reply to Frank Livingston:

    Hi Frank,

    I am using TI SDK RTOS 6.01.00.08.

    I configured uart with the help of driver functions. Yes, this is an internal loopback.

    Please suggest any solution to rectify this problem. 

    Please find attached .c file.uart_module.cuart.cuart_irda_cir.c

    Regards,

    Gaurav

  • In reply to Gaurav Aggarwal1:

    Gaurav,

    I surmise your test function is RS422_Test(). I notice you're using these CSL API functions:

        UARTFIFOCharPut(SOC_UART_0_REGS, txByte);

        rxByte = UARTFIFOCharGet(SOC_UART_0_REGS);

    Please see the descriptions of these CSL API functions in <PDK>\packages\ti\csl\src\ip\uart\V1\uart.h:

    /**
     * \brief   This API writes a byte to the Transmitter FIFO without checking for
     *          the emptiness of the Transmitter FIFO or the Transmitter Shift
     *          Register(TSR).
     *
     * \param   baseAddr     Memory address of the UART instance being used.
     * \param   byteTx      The byte to be transmitted by the UART.
     *
     *
     * \return  None
     *
     * \note    Unlike the APIs UARTCharPut() or UARTCharPutNonBlocking(), this
     *          API does not check for the emptiness of the TX FIFO or TSR. This
     *          API is ideal for use in FIFO mode of operation where the 64-byte
     *          TX FIFO has to be written with successive bytes. If transmit
     *          interrupt is enabled, it provides a mechanism to control the
     *          writes to the TX FIFO.
     */
    extern void UARTFIFOCharPut(uint32_t baseAddr, uint8_t byteTx);

    Note: "without checking for the emptiness

    /**
     * \brief   This API reads the data present at the top of the RX FIFO, that
     *          is, the data in the Receive Holding Register(RHR). However
     *          before reading the data from RHR, it does not check whether
     *          RHR has fresh data or not.
     *
     * \param   baseAddr     Memory address of the UART instance being used.
     *
     *
     * \return  The data read from the RHR.
     *
     * \note    1) Since this API does not check whether RX FIFO(RHR) has fresh
     *             data before reading the same, the application should ensure
     *             that RX FIFO has data before calling this API. The API
     *             UARTCharsAvail() can be used to check if the RX FIFO has
     *             atleast one byte of data.\n
     *          2) If the RX FIFO did not have any fresh data and this API is
     *             called, this API would return an unknown value.\n
     */
    extern int8_t UARTFIFOCharGet(uint32_t baseAddr);

    Note: "It doesn't not check whether RHR has fresh data or not" 

    Have you tried inserting larger delays?

    I suggest you experiment with these API functions instead:

    extern void UARTCharPut(uint32_t baseAddr, uint8_t byteTx);

    extern int8_t UARTCharGet(uint32_t baseAddr);

    extern uint8_t UARTCharGetTimeout(uint32_t baseAddr, uint32_t timeOutVal);

     

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    Yes, I tried with 50 ms delay but same problem.

    Thanks for your answer.

    I checked with your suggested APIs and UART but same problem is coming.

    I configured uart in one .c file and transmitting and receiving in another .c file then this problem is coming.

    But if I configure and do transmission in same .c file then this problem is not working. Why is it so?

    Mistakenly, I clicked on resolved. It is not resolved. 

    Regards,

    Gaurav

  • In reply to Frank Livingston:

    Frank,

    Yes, I tried with 50 ms delay but same problem.

    Thanks for your answer.

    I checked with your suggested APIs and UART but same problem is coming.

    I configured uart in one .c file and transmitting and receiving in another .c file then this problem is coming.

    But if I configure and do transmission in same .c file then this problem is not working. Why is it so?

    Mistakenly, I clicked on resolved. It is not resolved. 

    Regards,

    Gaurav

  • In reply to Gaurav Aggarwal1:

    Gaurav,

    >> But if I configure and do transmission in same .c file then this problem is not working

    I don't understand. Are you saying the problem doesn't occur when you have all the code (configuration, transmit, receive) in the same C file, but the failure occurs when the same code split into two separate C files?

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    Yes your are right. 

    Why is it so? 

    Regards,

    Gaurav

  • In reply to Gaurav Aggarwal1:

    Gaurav,

    Is there something different about how the single or split files are compiled (e.g. pre-defined symbols, optimization options, etc.)?

    Is there something different about how the code is linked for the two cases (check the .map file)?

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    I didn't change any compilation configuration or any configuration related to mapping too in both cases. 

    Let me check .map files then I'll let you know.

    Regards,

    Gaurav

  • In reply to Gaurav Aggarwal1:

    Hi Gaurav,

    I haven't heard back from you in ~1 week, so I'm assuming this issue has been resolved and I'm closing the thread. Please reopen the thread if you're still having an issue.

    Regards,
    Frank