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.

AM5716: After changing the pins of the console, input is not possible and there is no kernel log

Part Number: AM5716


The SDK version is,
Change uart3 pin from uart2 in hardware_ Rtsn/C28, uart2_ Ctsn/D27, switch to mcasp5_ Axr0/AB3, mcasp5_ Axr1/AA4,
The software has made the following changes:
Mux in uboot_ In data. h, added
{MCASP5_AXR0, (M4 | PIN_INPUT)},/* mcASP5_ Axr0.uart3_ Rxd*/
{MCASP5_AXR1, (M4 | PIN-OUTPUT)},/* mcASP5_ Axr1.uart3_ Txd*/
1. The startup log can be seen during the uboot stage, but the interrupt uboot startup cannot be inputted;
2. No kernel startup log;
3. After the system starts, it cannot be inputted, but after logging in using SSH, echo xxx>/dev/ttyS2 will be displayed in serial port 3;
After changing the console pins, are there any other areas that need to be changed besides the above modifications? Thank you for your guidance.



  • Hello Gary,

    A couple of questions to make sure I understand your issue:

    • You are able to get output from console, you are able to see u-boot prints? But cannot stop u-boot during the autoboot countdown?
    • Is this a custom board or TI evm?
    • I recently saw a similar issue with being enable to send inputs and changing the UART cable solved this
    • Are you trying to boot a prebuilt TI image or your own?


  • Hello,

    Thanks for your reply, here are my answers to your questions:

    1. You can see the output content of uboot, but it cannot be stopped during the automatic countdown;

    2. The board is a customized version;

    3. Hope to provide links to similar issues for reference;

    4. The images used are all compiled by ourselves, and some pin contents have been modified;

    5. Problem summary: The console can output content, but cannot respond to input. I hope to get help on other ways to enable sending input.



  • Hello Gary,

    Here locally, we solved this by changing our cable. It turned out we had a faulty cable. Have you tried?

    Please search e2e for similar issues:
    Here is one that was similar

    Can you read out the values of the pin mux registers:

    0x4A00374C & 0x4A003750 register values respectively to confirm if indeed the mux is set up properly for the UART?