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.

TMDX654IDKEVM: UART not operating properly

Part Number: TMDX654IDKEVM
Other Parts Discussed in Thread: MAX3232, TCA9555

Hi,

I have some problems regarding the UART on new my TMDX654IDKEVM. When initially booting the board from the provided SD card (int SD card boot mode), I get the following output when connecting to the first of the 4 available com ports from Tera Term:

A baud rate of 115200 is selected. It does appear from here that some information is received successfully, while other information is just Hexadecimal numbers. Is this the expected operation when initially booting from the SD Card(just giving it power)?

I went on to upload and test the ETH/CANgateway application project provided with the SDK. Everything works as expected in terms of operation of the CAN communication, Ethernet socket communication as well as printing to the CCS console with the printf() call in utils_prf.c of the gatewayapplication. However nothing is observed from the UART in Tera Term. The only data received over the UART is when initially uploading the program to the R5-core, with the observation seen below:

And once again only a few information is "readable":

Now as mentioned when running the application, nothing gets observed from Tera Term, only the output to the CCS console is observed correctly. According to my understanding of the software, UART instance 0 is configured as part of the application and should print to the UART AND the CCS Console from function call Utils_consoleprintf(). The UART_print() function call is thus not observed, although the printf call is.

Could you please provide some assistance in getting the UART connection fixed?

The ETH/CAN gateway application can be obtained from C:\ti\processor_sdk_rtos_am65xx_6_00_00_07\demos when the SDK is installed in the default directory.

The following is also true for my setup:

- Processor SDK: v6.00.00.07

- PDK: v1.0.5

- NDK v3.60.00.13

I hope to hear from you as soon as possible.

Kind regards,

Johnny

  • HI Johnny,

    I wanted to make sure that you had found the documentation for this demos and to see if it addressed your issues:

    http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_examples_demos.html#can-eth-gatway-demo

    Thanks.

  • Hi Ron,

    Yes, I know about that document. So no this does not solve my issue. The issue I have is to set up my UART.

    Even when I build, upload and  run the UART_testapp from the makefiles (for the R5 core), nothing gets observed from the Tera Term console.

    Johnny

  • Hi!

    Do you have any other advise? I say again, the problem is not with the gateway application, as the gateway application operates successfully and I have done further development on the board.

    The problem is just getting a simple communication through the UART (J42) and the PC. My setup is correct on the PC side (115200 Baud rate, 1 stop bit, no parity and I connect to the first available COM port), but I do not get any correct observations! I only observe debug information via the XDS110_USB connection.

    when I build the UART_TestApplication from the makefiles using:

    gmake uart LIMIT_BOARDS=am65xx_evm LIMIT_CORES=mcu1_0 (My build environment is set up correctly)

    and upload the binary (located at C:\ti\pdk_am65xx_1_0_5\packages\ti\binary), I still observe nothing over uart?

    I am booting from Debug mode (SW2 and SW3 has all switches off)

    Please can you assist in getting this simple setup fixed somewhere??

    Regards,

    Johhny

  • Hi Ron,

    I do not know what is going on with TI support currently? Why are there no replies?

    I finally got UART communication via the MCU_UART test header (J30) using a MAX3232 level translator and an RS232 cable to my PC. This works successfully, however I receive NO communication via the UART micro USB port which does not make any sense as this is the default uart port!

    If some data are occasionally received via the micro USB UART port, it is mostly just Hexadecimal that is received? Usually these are incorrect baud rate settings, however all my settings are correct according to the default UART parameters (115200 baud rate, 0 parity, 1 stop bit)?

    Regards

    Johnny

     

  • Johnny,

    I'm sorry for the delay. We will try to reply to this issue soon.

    Thanks.

  • Hi Johnny,

    Sorry for the late response.

    Johnny Smith said:
    A baud rate of 115200 is selected. It does appear from here that some information is received successfully, while other information is just Hexadecimal numbers. Is this the expected operation when initially booting from the SD Card(just giving it power)?

    The hex dump output is expected when booting up the platform, but it obviously is not what we want to see typically.

    The uart port which you connected to is not the debug console of U-Boot or Linux.

    I don't use Window/Tera-term but minicom in Linux, so I cannot explain why the first UART port Tera-term connected to is no the U-Boot/Linux debug console. In Linux, I would see the same hex output on the 3rd UART port with minicom in Linux.

    You might want to try to connect to each of the 4 UARTs to see which one is the U-Boot/Linux console.

  • Hi Bin,

    Thanks for you reply.

    So I have connected to each of the 4 com ports (again, have tried this), but I do not observe any of my UART_printf() calls to any of the 4 com ports. Not even hex or other dumps usually caused by baud rate issues. I do however observe the debug information from within CCS via the debugger and the printf() calls successfully.

    My UART is configured with default parameters (115200 baud, 0 parity 1 stop) by using the UART STDIO API and Board_init() calls. I do believe this is done correctly, as this is done like all the examples. I also do observe UART_printf calls successfully from the MCU_UART test header when using a max3232 level translator with an RS232 cable to my PC (This is not observed when a cable is plugged into the UART micro USB port (J42) though, I guess this has to do with Selection Logic when a cable is plugged in).

    So I am struggling to understand how I cannot get successful data transmission via the J42 as the software configuration appears to be successful as it is obverved from the test header?

    Regards,

    Johnny

  • I still have some problems with some of the UART virtual ports and the MCU_UART test header which I was hoping you could help me with. From the AM65XX IDK User Manual for the uart interface, the four COM ports observed via the micro usb is as follow:

    Currently I have only successfully connected to the MAIN_UART0(port 4 observed from TeraTerm) and the WKUP_UART0 (Port 1 observed from TeraTerm) via the micro usb port. When no cable is connected to the micro usb port, I can however successfully transmit uart data from the MCU_UART0 test header, using an RS232 level converter and connecting the TX,RX and GND pins. Receiving data via the test header from my PC is still unsuccessful and the software forever waits for the UART_read() function call.

    I initialize the uart (for both the R5 and A53 core) as follow, with the base address correctly set to the addresses specified in the TRM:

        //Inititializes the UART instances
        UART_init();
        UART_Params_init(&params);
        uart0 = UART_open(BOARD_UART_INSTANCE, &params);

    I thus have the following questions for the R5 core and MCU_UART0:

    1) I only receive data on the MCU_UART0 test header with UART_write() when no cable is plugged into the uart port. Why is that? I think it might have something to do with UART Selection Logic, if so please explain how I can select whether the peripheral should be test header or the FT4232.

    2) Why can I not observe any UART_read() fucntion calls from the test header? I only have Tx, Rx and GND connected. Are there any flow control enabled on this pin? If so, how can I disable it?

    3) Why do I not receive any UART_write() or UART_read() calls on any of the FT4232 virtual ports? Again I think this might something to the with UART Selection Logic maybe.

    UART_read() and UART_write() is successfully observed on the virtual COM port for MAIN_UART0 when software is uploaded on the A53 core. However, I want to connect to MAIN_UART1 successfully via this micro usb port as well. I create an instance for this port as follow:

        //Inititializes the UART instances
        UART_init();
        UART_Params_init(&params);
        uart1 = UART_open(BOARD_UART1_INSTANCE, &params);

    Now when calling the UART_write() and UART_read() functions on this uart instance, no data is observed on any of the virtual ports, even though the UART_write() function call returns successfully the amount of data transmitted.

    I thus have the following question regarding the A53 Core and MAIN_UART1:

    1) How can I connect to the MAIN_UART1 via the micro usb port?

    I really hope you can assist with some advise, as these uart ports are needed for our project.

    Regards,

    Johhny

  • Hi Johnny,

    Now I see the problems you have are more about UART programming in RTOS SDK, I would have to route your questions to our RTOS folks, (I am a Linux guy, and initially noticed you connected to a wrong UART port in Tera Term, so replied, but now all your questions are out of my expertise...), further response will be posted here.

    I do want to point out that if you check the EVM schematics, there is a 2:1 MUX (U65) on MCU_UART RX taking data either from the FTDI UART RX, or the MCU_UART header RX. So the MUX Select pin (MCU_UART_SEL signal) has to be programmed to either high or low to select one of the RX input, or MCU_UART won't be able to receive data from any of the two inputs.

  • Hi Bin,

    Thanks for your response. I look forward to hearing from the RTOS team as soon as possible.

    I previously was not able to connect to the UARTs due to incorrect baud rate settings on Windows itself. However that is fixed, now I just still need successful connection to MAIN_UART1 and MCU_UART0 via the FTDI usb port .

    I have previously noted the MUX select pin (MCU_UART_SEL signal), however I cannot find any information on how to configure and program this pin. Could you provide some info regarding how to program this pin?

  • Hi Johnny,

    Our RTOS expert is busy on another task at the moment, he will work on your case soon.

    Regarding the MCU_UART_SEL signal, it is the output pin16 of the I2C IO Expander (U110, TCA9555RTWR) on the EVM. I am not sure if RTOS already has a driver for TCA9555, but you would have to program it to drive this GPIO pin high or low to select the MCU_UART RX.

  • Hi Johnny,

    As mentioned by Bin, I think there is problem with the I2C IO Expander settings.

    From the AM654x IDK User's Guide (spruim6.pdf):

    From the AM654x IDK schematic:

    Following the highlighted signals in the schematic, it can be seen:

    • WKUP_UART_SEL is an input to the 2x1 mux U83. The level on this signal determines whether WKUP_UART0 Rx & CTS is routed to the WKUP UART header J11, or FT4232HL U73.
    • MAIN_UART1_SEL is an input to 8x4 mux/de-mux U26. The level on this signal determines whether MAIN_UART1 Tx, Rx, RTS & CTS are routed to the application header J16, or FT4232HL U73.
    • MCU_UART_SEL_IO_EXP is an input (indirectly) to the 2x1 mux U65. The level on this signal determines whether MCU_UART0 Rx & CTS are routed to the MCU UART header J30, or FT4232HL U73.

    Can you please try the following experiment and see if you're able to observe output on the MCU UART?

    • Following instructions for AM654x DMSC firmware load & EVM initialization here: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/index_how_to_guides.html#advanced-am65x-debug-setup-with-dmsc-firmware-load
    • Build UART example applications
      • cd pdk_am65xx_1_0_5\packages\ti\drv\uart
      • gmake apps LIMIT_BOARDS=am65xx_evm LIMIT_CORES=mcu1_0 BUILD_PROFILE="debug"
      • Resulting executable is here: pdk_am65xx_1_0_5\packages\ti\binary\UART_TestApp\bin\am65xx_evm\UART_am65xx_evm_mcu1_0TestApp_debug.xer5f
    • Power cycle EVM.
    • Launch TeraTerm. Connect to 1 of 4 USB UARTs provided by the EVM. Setting UART for 115200,8,parity=none,1, flow control=none. Repeat this for the remaining 3 USB UARTs.
    • Launch CCS.
    • Launch debugger, load & execute example application. You should observe output on two TeraTerm consoles, and no output on the other two TeraTerm consoles:
      • One TT console is for the WKUP UART. The output on this console is the hex values, and is the SYSFW log output.
      • The other TT console is for the MCU UART. The output on this console should be from the test program (see example below).

    When I tried this test, I observed the following:

    • COM5 - no output.
    • COM6 - MCU UART output.
    • COM7 - WKUP UART output.
    • COM8 - no output.

    The test program output began like this:

    UART UT 1

    UART non-DMA read write test in block mode

    enter the data of 16 character

     

    I verified the COM6 output is for the MCU UART by stepping into the UART driver UART_open() function. Inside UART_open_v1(), I see that:

    (struct UART_HWAttrs *)UART_config[0].hwAttrs.baseAddr = 0x40A00000

    This is the base address of the MCU UART.

    There are APIs for configuring the I2C IO expander here: pdk_am65xx_1_0_5\packages\ti\board\src\evmKeystone3\board_i2c_io_exp.c

    Example usage of the APIs can be seen here: pdk_am65xx_1_0_5\packages\ti\board\diag\led_industrial\src\led_industrial_test.c

    I'm still experimenting with these APIs, but I think they should allow you to route the UART signals to the desired location on the EVM.

    Regards,
    Frank

  • Johnny,

    I rebuilt the UART test program for A53: gmake apps LIMIT_BOARDS=am65xx_evm LIMIT_CORES=mpu1_0 BUILD_PROFILE="debug"

    I checked I'm able to see UART output for MAIN UART 0. In this case, I see output on COM5, and none on COM6 for the MCU UART.

    Next I tried a quick experiment where I changed this code in main_test_uart.c:UART_getTestInstNum():

        *instNum = BOARD_UART1_INSTANCE;//UART_INSTANCE;

    Unfortunately I don't see any MAIN UART1 output. I see power and clocks have been configured for MAIN UART 1. Hence I suspect the I2C IO Expander settings are incorrect, the pin mux settings are wrong, or both. I'll dig into this further and keep you posted on what I find.

    Regards,
    Frank

  • Hi Frank,

    Thanks so much for your detailed explanation, it is much appreciated. Even with your step by step explanation, I still have no success on observing MCU UART output via the FT4232HL. This is I do not understand. Please see my steps

    • I build the UART example test application.
    • I setup up Tera Term (115200 baud, 8 data, 1 stop, no parity) and connect to all 4 COM ports associated with the FT4232HL (Here it is COM 8,10,11,12)
    • Upload DMSC firmware and setup the EVM. Here I have attached the GEL output:
      EVM setup.txt
      DMSC_Cortex_M3_0: GEL Output: Configuring AM65xEVM...
      DMSC_Cortex_M3_0: GEL Output: Init value actual value: 0x00000888
      DMSC_Cortex_M3_0: GEL Output: Register value: 0x00000888
      DMSC_Cortex_M3_0: GEL Output: ATCM is on
      DMSC_Cortex_M3_0: GEL Output: ATCM configured.
      DMSC_Cortex_M3_0: GEL Output: Assuming execution from M3.
      DMSC_Cortex_M3_0: GEL Output: This script sets the first address translation region to [0x8000_0000, 0x0000_0000].
      DMSC_Cortex_M3_0: GEL Output: It also sets the second address translation region to    [0x6000_0000, 0x4000_0000].
      DMSC_Cortex_M3_0: GEL Output: Setting all PLLs in progress. This may take some time.
      DMSC_Cortex_M3_0: GEL Output: 0 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 10 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 20 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 30 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 40 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 50 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 60 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 70 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 80 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: 90 Percent Complete...
      DMSC_Cortex_M3_0: GEL Output: Setting all PLLs done!
      DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains in progress...
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_COMMON
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DMSC
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MCU
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MAIN_INFRA
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DEBUG2DMSC
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_GPIO
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN_INFRA
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2WKUP
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN2MCU
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_COMMON
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_TEST
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_0
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_1
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_0
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_1
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_HYPERBUS
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_DEBUG
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_0
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_1
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_INFRA
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_TEST
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_PBIST
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CC_TOP
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_2
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_3
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_DEBUG
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DSS
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MMC
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CAL
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SAUL
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PER_COMMON
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_NB
      DMSC_Cortex_M3_0: GEL Output: No change needed.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_0
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_1
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_2
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_GPU
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_DATA
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_CFG
      DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
      DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains done!
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      
      DDR not initialized with R5 connect.
      
      Go to menu Scripts --> DDR_Initialization to initialize DDR.
      
      ====
      
      MCU_PULSAR_Cortex_R5_0: GEL Output: base = 0x43000000
      MCU_PULSAR_Cortex_R5_0: GEL Output: offset = 0x0001C040
      MCU_PULSAR_Cortex_R5_0: GEL Output: partition = 0x00000007
      MCU_PULSAR_Cortex_R5_0: GEL Output: Partition successfully unlocked!
      MCU_PULSAR_Cortex_R5_0: GEL Output: Partition successfully locked!
      MCU_PULSAR_Cortex_R5_0: GEL Output: VTT Regulator Enabled 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      PHY Init complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000000F
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for DRAM Init to complete... 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      DRAM Init complete
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000001F
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for write leveling to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write leveling done 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000003F
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write Leveling completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Read DQS training to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read DQS training done 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000007F
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read DQS training completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Write leveling adjustment to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write leveling adjustment done 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800000FF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write Leveling Adjustment completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Read deskew to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read deskew complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800001FF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read Deskew completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Write deskew to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write deskew complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800003FF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write Deskew completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Read Eye training to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read Eye training complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800007FF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Read Eye Training completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for Write Eye training to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write Eye training complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80000FFF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Write Eye Training completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      Waiting for VREF training to complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      VREF training complete 
      MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      VREF Training completed successfully 
      MCU_PULSAR_Cortex_R5_0: GEL Output: 
      
      ====
      DDR4 Initialization has PASSED!!!!
      DDR is configured for 800MHz operation
      ====
      
      

    -I upload and execute the test application. Unfortunately, I only observe the WKUP UART output. Please see the below screenshot of all COM ports:

    When stepping into UART_open_v1(), I also observe a base address of 0x40A00000 and intNum of 30, which both correspond to that of the MCU_UART0.

    This does not make sense to me. The UART_write function returns successfully on the correct instance as well, however no output is observed. Another thing to note is in Windows Device Manager, all COM ports are also configured as follow:

    I am starting to get a bit desperate now. Do you please have any other advice?

    I look forward to hearing from you! Thanks again for your very good explanations.

    Regards,

    Johhny

  • Hi Johnny,

    Thanks for sharing your GEL file output. I notice some differences between our outputs.

    Here is the GEL file output I observe after power cycling the board: 

    evm_setup_log_power_cycle.txt
    DMSC_Cortex_M3_0: GEL Output: Configuring AM65xEVM...
    DMSC_Cortex_M3_0: GEL Output: Init value actual value: 0x00000888
    DMSC_Cortex_M3_0: GEL Output: Register value: 0x00000888
    DMSC_Cortex_M3_0: GEL Output: ATCM is on
    DMSC_Cortex_M3_0: GEL Output: ATCM configured.
    DMSC_Cortex_M3_0: GEL Output: Assuming execution from M3.
    DMSC_Cortex_M3_0: GEL Output: This script sets the first address translation region to [0x8000_0000, 0x0000_0000].
    DMSC_Cortex_M3_0: GEL Output: It also sets the second address translation region to    [0x6000_0000, 0x4000_0000].
    DMSC_Cortex_M3_0: GEL Output: Setting all PLLs in progress. This may take some time.
    DMSC_Cortex_M3_0: GEL Output: 0 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 10 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 20 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 30 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 40 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 50 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 60 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 70 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 80 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: 90 Percent Complete...
    DMSC_Cortex_M3_0: GEL Output: Setting all PLLs done!
    DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains in progress...
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_COMMON
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DMSC
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MCU
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MAIN_INFRA
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DEBUG2DMSC
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_GPIO
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN_INFRA
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2WKUP
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN2MCU
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_COMMON
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_TEST
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_0
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_1
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_0
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_1
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_HYPERBUS
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_DEBUG
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_0
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_1
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_INFRA
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_TEST
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_PBIST
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CC_TOP
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_2
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_3
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_DEBUG
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DSS
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MMC
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CAL
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SAUL
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PER_COMMON
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_NB
    DMSC_Cortex_M3_0: GEL Output: No change needed.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_0
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_1
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_2
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_GPU
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_DATA
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_CFG
    DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
    DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains done!
    MCU_PULSAR_Cortex_R5_0: GEL Output: VTT Regulator Enabled 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    PHY Init complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000000F
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for DRAM Init to complete... 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DRAM Init complete
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000001F
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for write leveling to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write leveling complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000003F
    MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX0GSR0 = 0x00892120
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX1GSR0 = 0x008C21A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX2GSR0 = 0x008F23A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX3GSR0 = 0x008E22A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read DQS training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read DQS training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000007F
    MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX0RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX1RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX2RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX3RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write leveling adjustment to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write leveling adjustment complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800000FF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read deskew to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read deskew complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800001FF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write deskew to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write deskew complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800003FF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read Eye training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read Eye training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800007FF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write Eye training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write Eye training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80000FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for VREF training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    VREF training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    
    ====
    
    DDR4 Initialization has PASSED!!!!
    
    ====
    
    MCU_PULSAR_Cortex_R5_0: GEL Output: VTT Regulator Enabled 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    PHY Init complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for DRAM Init to complete... 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DRAM Init complete
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for write leveling to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write leveling complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX0GSR0 = 0x00892120
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX1GSR0 = 0x008C21A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX2GSR0 = 0x008F23A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX3GSR0 = 0x008E22A0
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read DQS training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read DQS training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX0RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX1RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX2RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    DDRSS_DDRPHY_DX3RSR0 = 0x00000000
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write leveling adjustment to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write leveling adjustment complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read deskew to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read deskew complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write deskew to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write deskew complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Read Eye training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Read Eye training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for Write Eye training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Write Eye training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    Waiting for VREF training to complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    VREF training complete 
    MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
    MCU_PULSAR_Cortex_R5_0: GEL Output: 
    
    ====
    
    DDR4 Initialization has PASSED!!!!
    
    ====
    
    

    Have you modified the GEL files?

    What version of the Sitara & common device support package do you have installed? To check this in CCS: Help->Install New Software, click "already installed", browse down to "Shared Device Support". I have the following:

    • Shared Device Support: 1.1.1
    • Sitara Device Support: 1.4.5

    I've made a couple of modifications to the <PRSDK install folder>\pdk_am65xx_1_0_5\packages\ti\drv\sciclient\tools\ccsLoadDmsc\am65xx\launch.js as shown below. I don't think these should make a difference, but can you please check if this makes a difference for you?

    //<!!!!!! EDIT THIS !!!!!>
    // Set this to 1 to allow loading the GEL files directly from the ccxml file.
    //disableGelLoad = 0; // FL
    disableGelLoad = 1;

    // Path to the directory in which this file would be residing. CCS expects
    // absolute paths to load the binaries.
    //thisJsFileDirectory = "pdk/packages/ti/drv/sciclient/tools/ccsLoadDmsc";
    thisJsFileDirectory = "R:/pdk_am65xx_1_0_5/packages/ti/drv/sciclient/tools/ccsLoadDmsc"; // FL

    A few other things to check include:

    [MCU_PULSAR_Cortex_R5_0]
    DMSC Board Configuration with Debug enable
    DMSC Firmware Version 19.4.1-v2019.04a (Curious Crow)
    Firmware revision 0x13
    ABI revision 2.6
    DDR PLL set to 400.000000 MHz

     

    Regards,
    Frank

  • Johnny,

    One other thing to check is whether the MCU UART outputs anything when the EVM is configured in UART boot mode.

    To select the UART boot setting:

    SW3.4:on, SW3.3:off, SW3.2:on, SW3.1:off

    The UART will repeatedly output the character 'C':

    Regards,
    Frank

  • Hi Frank,

    Thanks for your reply! I really do aprreciate your efforts.

    I do note that the GEL output seems to differ for the R5 core initilization, however I have not edited any of the GEL files. I only edited the the launch.js file to include the correct directories for CCS910 and the SCICLIENT tools:

    //<!!!!!! EDIT THIS !!!!!>
    // Set this to 1 to allow loading the GEL files directly from the ccxml file.
    //disableGelLoad = 0;
    disableGelLoad = 1;
    
    if (disableGelLoad == 0)
    {
        //Path to GEL files
        //gelFilePath = "C:/ti/ccsv8/ccs_base/emulation/boards/am65x/gel/";
    	gelFilePath = "C:/ti/ccs910/ccs/ccs_base/emulation/boards/am65x/gel/";
    }
    // Path to the directory in which this file would be residing. CCS expects
    // absolute paths to load the binaries.
    //thisJsFileDirectory = "pdk/packages/ti/drv/sciclient/tools/ccsLoadDmsc";
    thisJsFileDirectory = "C:/ti/pdk_am65xx_1_0_5/packages/ti/drv/sciclient/tools/ccsLoadDmsc";
    //<!!!!!! EDIT THIS !!!!!>

    However when changing disableGelLoad to 1, no difference is made as expected. Other points:

    • It appears as if my board support packages differ with yours. I have the following installed:

    - Shared Device Support: 1.1.3

    - Sitara Device Support:    1.4.7

    I assume this can allow for different GEL files and thus an incorrect setup of the boards. I am struggling to find the versions that you have online so that I can install it on my PC.

    • FTDI driver was installed successfully by Windows automatically.
    • I am booting in "No Boot' Mode the whole time, in other words, all switches (SW4 and SW3) are in the off position.
    • I have the exact same output as you in the CIO window, thus I have the exact same DMSC firmware version.

    With regards to the UART boot setting, I have booted with the Bootmode switches as mentioned. I still receive no MCU UART via the FT4323H. However I have 5 TeraTerm COM ports open at the moment, 1 that connects to MCU_UART test header via the RS232 port on my PC, and the other 4 is the FT4323H COM ports. When I remove the FT4323H USB cable while in UART boot mode, I iimmediately start observing the repeated output C character on the MCU_UART test header. The MCU_UART thus operates successfully, but clearly somewhere something in my configurations with the FT4323H and the MCU_UART there is something wrong. I guess this has to have to do with differnet Sitara and Shared Device support, or the incorrect automatic installation of the FTDI drivers? I think the latter is unlikely though, as I do observe successful output on the other COM ports (MAIN_UART0 and WKUP_UART)

    I have tried different USB ports on my PC, and moving it to different COM ports in Windows Device Manager as well, without success.

    I look forward to hearing from you on any advice from here, however in the meantime I will try to install other FTDI driver versions, as well as try to locate and install the device support packages that you have.

    Once again, I reallly do appreciate your very thorough explanations.

    Kind regards,

    Johnny

      

  • Hi Johnny,

    I doubt the device support packages are causing a problem since these won't affect UART boot.

    Nevertheless I tried the following combination, and the UART test example still works on R5F with the MCU UART:

    • Shared Device support: 1.1.3
    • Sitara Device support: 1.4.8

    Looking at the IDK schematic, I notice the MCU UART Tx signal is simultaneously routed to both FTDI and the MCU UART Test Header J30, and I don't see any hardware which selects one of these these two signal destinations as active while deactivating the other destination.

    As an experiment, I tried the following:

    • set EVM in UART boot mode
    • connected a scope to J30, pin 5 (TXD) & USB UART over FTDI via J42 to PC
    • power cycled board
    • on PC, connected TeraTerm to USB UART for MCU UART

    In this case, I observe:

    • continuous 'C' on the TeraTerm output. Note the frequency of the 'C' is about 1 / sec., so kind of slow.
    • continuous '0 1 1 0 0 0 0 1 0 1' on the scope. ASCII 'C' is 0 1 0 0 0 0 1 1 0', so this is the correct UART Tx for 'C' with MSB first (w/ Start bit, no Parity, and 1 Stop bit).

    If I disconnect the FTDI cable, the TeraTerm console stops working, so I need to reconnect TeraTerm. The output on J30 is not stopped by disconnecting the cable.

    I haven't tried this yet, but it would be interesting to see if we could connect a scope to FT4232_UART0_TX_3V3.

    I understand you observe output on MAIN_UART0 and WKUP_UART, but I think the current evidence we have points to the PC FTDI drivers.

    Regards,
    Frank

  • Hi Frank,

    I uninstalled/reinstalled the drivers on all COM ports (used the method described on FTDI installation guides). Issue still persists.

    I also then set up a Windows 10 Virtual Machine and installed Tera Term on it to simulate a different PC. I then connected the FTDI USB uart to the virtual machine and tried to observe MCU UART output from there (maybe there is an error in my local PC windows COM port configuration such that Windows gets very confused).

    However, the output observed on the Virtual Machine is still the same with UART test app:

    - WKUP UART is observed when uploading/starting the debugger etc.

    - MAIN UART0 is observed and the UART test_app operates successfully and passes all tests via FT4232H. (uploading .xa53f binary on A53_0 core)

    - MCU UART observes nothing via FT4232H. (.xer5f binary on R5 core) Only when removing the USB cable, the first test is printed as "failed" to the MCU_UART test header:

    The same goes for UART bootmode:

    - No output is observed via the FT4232H (on any of the 4 COM ports), only when the USB cable is removed, the "C" character gets printed to the 5th COM port, which is the MCU_UART test header.

    I even tried to stupid things like swapping the COM ports around to match the order as mentioned in 10.3.1.1.3 UART connection. No success still.

    What FTDI driver version do you have installed, and on what Windows version?

    I also cannot see any other hardware configuration issues that might affect this. MCU_BOOTMODE switches maybe (SW4)? Here ALL my switches are in the OFF position, including ALL on SW2, SW3 and SW4. I am seriously stuck with regards to this and it is starting to get to me.

    I do hope we can sort this out as soon as possible.

    Kind regards

    Johny

  • Hi Johnny,

    I'm using Windows 10 Pro.

    I recently received a new Windows PC, and I never explicitly installed the FTDI drivers. This is what I see on my PC:

    According to the IDK UG (spruim6.pdf), the FTDI drivers can be obtained from here: https://www.ftdichip.com/Products/ICs/FT4232H.htm

    A few things to try:

    • Have you tried another physical PC?
    • Have you tried another EVM? Maybe something is wrong with U12 on your EVM.
    • Can you inspect FT4232_MCU_UART1_RX_3V3 in UART Boot mode? This would show whether the MCU UART Tx is working from the SoC. I haven't checked whether this signal is easily accessible anywhere on the EVM.

    Regards,
    Frank

  • Johnny,

    I double checked the EVM for any jumpers which might cause this issue, but I don't see any such jumpers.

    If you do a final check on the FTDI driver and the MCU UART still isn't working in UART Boot mode, then I'm starting to think this is an EVM hardware issue. In that case I'll loop in an EVM hardware expert.

    Regards,
    Frank

  • Hi Frank,

    That is the driver that Windows installed automatically through Windows update as well. When installing the drivers provided on the FTDI website, it appears to be a different version, however the same result. Observing WKUP and MAIN UART1, but not MCU UART. The port settings for each COM port (within device manager) is also selected to be 115200 baud, 8 data, 1 stop, no parity.

    I tried a different PC. Same results.

    Unfortunately, this is the only EVM I have. It is quite new as well, I think only 2 weeks old.

    The FT4232_MCU_UART1_RX_3V3 is not at all easily accessible, so I am not to sure as to how I will have to go about inspecting this signal. This signal according to me is only connected on U12 itself (which is extremely small) and the FT4232H chip (where it is also small and difficult to access). 

    I agree that from the evidence we have, the problem should lie between the U12 and the PC FTDI driver. However having installed different FTDI drivers, and having tried testing it on different PC's, there is still no success on observing MCU_UART in UART boot mode. 

    Regards,

    Johnny

  • Johnny,

    I'm looping in our hardware expert, and investigating how the EVM can be replaced if it turns out to be a hardware problem. How did you obtain the EVM?

    Regards,
    Frank

  • Hi Johnny,

    Can you provide the details on the revision of the board that you are using and the serial number?

    Regards, Bill

  • Hi Frank,

    Thanks for all your assistance! I ordered and obtained the EVM from the TI website.

    Kind regards,

    Johhny

  • Hi Bill,

    Please see below, accorging to the onboard silkscreen and stickers:

    Development board:

    Serial nr 39184P810011

    - Rev 1.0

    Application card:

    - Serial nr 38184P820012

    Rev 1.0

    PCIe:

     - Serial nr 36184P880107

     - Rev 1.0

    I hope to hear from you soonest, please let me know if anything else is required.

    Regards,

    Johnny

  • Hi Johnny,

    I have read through the forum post and I see you have done some fairly extensive testing using the MCU_UART test port. I wanted to determine the version of the board which should be E3.  The E2 version of the board did have a problem with the MCU_UART port but that was corrected it E3.

     .

    I wanted to concentrate for a moment on the statement that the UART boot characters were only present when the USB was not connected. Can you connect to the device with code composer if the USB cable is connected? Do you have access to an oscilloscope to probe the TX pin on J30?  I am trying to determine if there is any effect to the signal or signal levels if the USB is connected. Since the TX signal is connected to both the FTDI voltage translator and the MCU_UART voltage translator, the characters should not stop regardless of whether the USB is connected. If the signal level at the MCU UART test connector is effected that may point to a problem with the board.

    Regards, Bill

  • Hi Johnny,

    I think this is where you would go to check for returns / exchanges.

    http://www.ti.com/info-store/help/returns-refunds-and-cancellations.html

    Regards,
    Frank

  • Hi Bill,

    My version of the board is E3.

    Just to again quickly explain hardware setup. My MCU_UART test header Tx and Rx pin are connected via an MAX3232 level translator to the RS232 port on my PC. This is COM1. The other 4 COM ports detected when plugging in a USB cable to the FT4232H, is COM3,4,6,10 (I have tried changing to literally all other ports as well). I have successfully transmitted UART data over COM3(MAIN1) and COM6 (WKUP). MCU_UART should obviously be one of the other two. Within windows device manager, all COM port drivers are the same, with same settings (115200 baud, 8 data, 1 stop, no parity). The same goes for Tera Term setup.

    Unfortunately, I do not have an oscilloscope (I will try to organize one over the weekend). However, when I boot the board in UART boot mode (with usb plugged in), I receive nothing on any of the open TeraTerm COM ports. After unplugging the USB cable after about a minute, I receive the 'C' character on COM1, which is MCU_UART test header.

    The 'C' character gets printed out continously about every 2 seconds. When I plug the USB cable back in, COM1 observations stops. When I remove it again, it continues. In the meantime, nothing is observed on any FT4232H COM ports.

    I guess observing this over an ossciloscope should be best. Hopefully I can organize one as soon as possible.

    Regards

    Johnny

  • Hi Johnny,

    I'm sorry for the delay in responding.  I did test an AM65x EVM and observed that the characters do continue to appear on the MCU_UART port regardless if the USB connection is present. Have you been able to confirm that the UART signal is not present if the USB cable has been removed? 

    Regards, Bill

  • Hi Bill,

    I will keep you updated as soon as my oscilloscope have arrived. Still waiting on it to be delivered.

    Regards,

    Johnny

  • Hi Johnny,

    I am just checking to see if you have any additional questions.  

    Regards, Bill

  • Hi Bill,

    Thanks for checking up, however I am still waiting on a oscilloscope to be deliverd so that I can test whether the "c" character gets output to the test header regardless of a connected usb cable. It is expected to arrive on Friday or Monday. In the meanwhile I am working on other parts of our application.

    However, regardless of the outcome of the test, I think I will still have questions. I mean if the "c" character does in fact get printed to the test header, we will probably have to investigate further the cause of the problem and if not, I assume the development board is faulty and probably then has to be replaced?

    However I will keep you updated as soon as I have more info!

    Thanks again!

    Regards, Johnny

  • Hi Bill,

    So I have an update... NO data is received when a USB is connected and measuring the TX pin of MCU_UART test header. Please see the test below:

    When a USB is not connected and I set the scope to a single trigger, the C characther gets displayed on the TX pin (See below oscilloscope screenschot):

    However, when removing the the USB cable from the UART USB port, the scope does not get triggered again. This indicates that no data is transmitted when a USB cable is connected. Only when removing the USB cable again, the C character gets transmitted on the TX pin again.

    Clearly, there should be something wrong with the development board then? Where to go from here then?

    Kind regards,

    Johnny

  • Hi Johnny,

    I'm sorry the EVM isn't working properly.  Please visit the return site below to return the defective unit for an exchange.

    https://www.ti.com/productreturns/docs/createReturn.tsp

    Please let me know if you have any issues.

    Regards, Bill

  • Hi Bill,

    Seeing that it is only the MCU_UART that gives issues, I can still work on other aspects and components of our application. Is it thus possible to put a hold on the return process for now just so that I can continue development? I can then send it back in the first week of December if that is acceptable?

    If I log a return request, will we I have to send it back immediately or can we arrange that I can send it back in a few weeks time?

    Please let me know who I can contact and where with regards to this. I also need information regarding what the return policy is in terms of who pays for the shipping etc. etc.

    I am just careful to immediately submit a return request, as it is still important for me to continue development. However if it is not possible otherwise, I guess I will have to return it ASAP.

    Kind regards,

    Johhny

  • Hi Johhny,

    I'm not directly involved in the return process but it is a defective board so I don't believe that delaying the return by a few weeks should matter. I will attempt to contact the team in TI that handles that for clarification.

    Regards, Bill

  • Hi Johnny, 

    I've been told that the return is in process.  Let me know if you have any other questions.

    Regard, Bill

  • Hi Bill,

    Yes, return is in process. In the meantime I have managed to program MCU_UART_SEL pin so that the Rx can be routed via the test header, so at least we can test some functionality.

    With this I will be marking this issue as resolved. Thanks for all your assistance!

    Kind regards,

    Johnny