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.

  • TI Thinks Resolved

RTOS/AM3359: Problem using UART4 on ICEV2 with PRU-ICSS pinmux

Prodigy 180 points

Replies: 22

Views: 646

Part Number: AM3359

Tool/software: TI-RTOS

I have a project that is built off of the NIMU_ICSS Example Project using the PRU as a dual MAC. The PRU functionality works well and is using UART3 for debug terminal. 

I am attempting to simply enable UART4 which is pinned out to header J3 on the development board. If I call the initialization code below I do not see any output on the UART Tx line. 

UART_Handle handle;
UART_Params params;

UART_Params_init(&params);
params.baudRate = 115200;
params.writeDataMode = UART_DATA_BINARY;
params.readDataMode = UART_DATA_BINARY;
params.readReturnMode = UART_RETURN_FULL;
params.readEcho = UART_ECHO_ON;
handle = UART_open(4, &params);
if (!handle) {
System_printf("UART did not open");
}

// new UART should be open, so lets send some data to it
const unsigned char testStr[] = "Test: Hello World!\n";

int32_t retVal = UART_write(handle, testStr, sizeof(testStr));
UART_printf("new UART printed %d characters\n", retVal);

In main I am calling the following Board_init cfg:


Board_initCfg cfg = BOARD_INIT_PLL| BOARD_INIT_MODULE_CLOCK | BOARD_INIT_DDR | BOARD_INIT_ICSS_PINMUX | BOARD_INIT_UART_STDIO | BOARD_INIT_ICSS_ETH_PHY;
ret = Board_init(cfg);
if (ret != BOARD_SOK)
{
UART_printf("main: Board_init returned error code: %d\n", ret);
return -2;
}

If I examine the pinmux file, iceV2AM335x_pinmux.c, I see that UART4 should be being configured:

/* UART */
status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 1U, NULL);
if(S_PASS == status)
{
status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 3U, NULL);
}
if(S_PASS == status)
{
status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 4U, NULL);
}

So... what is the obvious thing I am missing? 

  • Hello,
    did you use the function "PRCMModuleEnable()" in some other part of your code?
    It should be called in order to enable the UART instance.
    BR
    Michail

  • In reply to Michail Georgiev:

    Michail,

    Thanks for the reply. In main I am calling:

    Board_initCfg cfg = BOARD_INIT_PLL| BOARD_INIT_MODULE_CLOCK | BOARD_INIT_DDR | BOARD_INIT_ICSS_PINMUX | BOARD_INIT_UART_STDIO | BOARD_INIT_ICSS_ETH_PHY;
    ret = Board_init(cfg);

    Would this not call Board_moduleClockInit() as configured in the icev2AM335x.c file? This file includes the following line:

    status = PRCMModuleEnable(CHIPDB_MOD_ID_UART, 4U, 0U);

    So, I believe the clock for the module is being configured.

    Let me know if you have a suggestion on how to confirm this, or further suggestions.

    Thank you!
  • In reply to Nicholas Begley:

    Nicholas,

    Couple of minor sanity checks:
    1. To confirm the pinmux setup, have you read back the Mux mode to confirm Have you imported the pinmux project and checked the pin setup has both enabled.
    2. Does the UART work with PRU ICSS related pinmux taken out . If that is the case there is some conflict.
    3. Software numbers UART instance from 0, N-1 so make sure that you are using the correct instance.
    4. How are you testing the UART functionality. there is only one debug UART so have you hooked up a scope to TX and RX.

    Please refer to this document that walks user though all steps to enable use of custom UART instance to see if you missed any step:
    www.ti.com/.../sprac32a.pdf

    Hope this helps.

    Regards,
    Rahul

    --------------------------------------------------------------------------------------------------------------------------------------
    Please click the
    This resolved my issue button on this post if the responses on this E2E thread answers your question.
    --------------------------------------------------------------------------------------------------------------------------------------

     

  • In reply to Rahul Prabhu:

    You say:

    1. To confirm the pinmux setup, have you read back the Mux mode to confirm Have you imported the pinmux project and checked the pin setup has both enabled.

    If you are referring to the PinMux utility, yes I have imported the icev2_config.pinmux file and regenerated the pinmux files (attached) according to the instructions in the pdf (obviously changining from Beaglebone to am335x_icev2). And how do I read back the pinmux mode? That would be very helpful.

    2. Does the UART work with PRU ICSS related pinmux taken out . If that is the case there is some conflict.

    I have now switched over to using the UART example project. The UART3 works correctly, through the USB -serial interface, as my debug output. So my boardCfg now looks like:

       boardCfg = BOARD_INIT_PINMUX_CONFIG |

                  BOARD_INIT_MODULE_CLOCK  |

                  BOARD_INIT_UART_STDIO;

    And I am still not able to initialize UART4.

    3. Software numbers UART instance from 0, N-1 so make sure that you are using the correct instance.

    Yes, I am trying to initialize instance 4 which comes out to header J3 pin 7 and pin 8 on the ICEV2 board. So I am calling

    handle = UART_open(4, &params);

    Is this the correct instance index? This seems correct to me.

    4. How are you testing the UART functionality. there is only one debug UART so have you hooked up a scope to TX and RX.

    I have a scope on both TX and RX. I see no wiggle...

    8561.am335x_icev2_pinmux_data.c

    3755.am335x_pinmux.h

  • In reply to Nicholas Begley:

    Any further suggestions or input on this issue?

    Specifically, how do I verify the mux mode as suggested?

    Any other things to try? I have successfully initialized SPI and GPIO peripherals with no issue, so the only thing holding me up now is the uart.

    Thanks for your help.
  • In reply to Nicholas Begley:

    Nicholas Begley

    1. To confirm the pinmux setup, have you read back the Mux mode to confirm Have you imported the pinmux project and checked the pin setup has both enabled.

    If you are referring to the PinMux utility, yes I have imported the icev2_config.pinmux file and regenerated the pinmux files (attached) according to the instructions in the pdf (obviously changining from Beaglebone to am335x_icev2). And how do I read back the pinmux mode? That would be very helpful.

    Michael,

    I created some scripts that can do this.  First, please download this file:

    http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/raw/master/padconf/am335x-padconf.dss

    You're going to use JTAG/CCS in conjunction with that file to "scrape" the padconf registers from the target.  Please follow these directions:

    http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/master/README

    The output will be a rd1 file.  

    If you're a "do it yourselfer" you can run the python script to decode the pinmux file yourself. You would start by cloning this entire repository:

    git://git.ti.com/sitara-dss-files/am335x-dss-files.git

    It contains the python script and necessary xml files to decode the rd1 file. More details can be found in this README (note this is a different README than the first one I referenced):

    http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/master/padconf/README

    Alternatively, you can zip up the rd1 and attach it here and I can run it through the python script on my side.  So please either attach the rd1 file or the csv file.  This will give us a quick view of your entire pinmux to see if there might be any other issues lurking.

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Sorry for slow response. 

    Well, this was a very helpful suggestion, and it seems to have clarified that my pinmux config is not correct. 

    Attached is the processed padconf file. This seems to show that the pins I am trying to enable (E17, E18) as UART4 are enabled as GPIO. 

    conf_ecap0_in_pwm0_out 0x44E10964 0x00000017 fast output-only pullup 7 gpio0_7
    conf_uart1_ctsn 0x44E10978 0x00000037 fast input enabled pullup 7 gpio0_12

    So I believe I now realize that I missed the step of rebuilding the sdk. However, my compilation is failing when I run gmake board. 

    It fails with the following output: 

    # Compiling am335x:pru_0:icss_i2c: src/I2C_scheduler.asm
    c:\ti/ti-cgt-pru_2.2.1/bin/clpru -DMAKEFILE_BUILD -v3 -g --endian=little -DICSS_REV1 --diag_wrap=off --diag_warning=225 --display_error_number --hardware_mac=on --preproc_with_compile -eo.opru -DPRU0 -Dpru0 -DPRU -DSOC_AM335x -IC:/ti/ccsv6/ccs_base/pru/include -Ic:\ti/ti-cgt-pru_2.2.1/include -Isrc/ -IC:/ti/pdk_am335x_1_0_13/packages/ti/csl/ -IC:/ti/pdk_am335x_1_0_13/packages/ -fr=C:/ti/pdk_am335x_1_0_13/packages/ti/binary/icss_i2c/obj/am335x/a8host/REV1/pru_0 -fs=C:/ti/pdk_am335x_1_0_13/packages/ti/binary/icss_i2c/obj/am335x/a8host/REV1/pru_0 --preproc_dependency="I2C_scheduler.d" src/I2C_scheduler.asm
    c:ti/ti-cgt-pru_2.2.1/bin/clpru: not found

    So I am stuck again...

  • In reply to Nicholas Begley:

    Nicolas,

    You can see the the build issue that is reporting indicates that you have not set the path the PRU compiler correctly. The PRU compiler is part of the release but the path that is picking up has a mix of forward and back slashes which ultimately results in the build unable to find the PRU compiler in your environment.

    Regards,

    --------------------------------------------------------------------------------------------------------------------------------------
    Please click the
    This resolved my issue button on this post if the responses on this E2E thread answers your question.
    --------------------------------------------------------------------------------------------------------------------------------------

     

  • In reply to Rahul Prabhu:

    Yes, thanks. 

    That problem turned out to simply be that I had defined my TOOLS_SETUP_PATH as "C:ti\" (backslash) when I needed to set it as "C:ti/" (forward slash). 

    Still however, I am unable to change my pin IO configuration. I am following the directions in the sprac32a.pdf document. I am, of course, adapting it for this case of using the TMDSICE3359 board. So, where it indicates I should modify gAM335xPinmuxData[] to be gBbbPinmuxData[], I am instead modifying it to be gIceV2PinmuxData[]. 

    So, to be clear, I am modifying the generic named file am335x_pinmux_data.c to be instead am335x_icev2_pinmux_data.c and am replacing the existing am335x_pinmux.h file with that generated by the TI Pinmux cloud tool. 

    However, when I then attempt to rebuild the starterware package I get the following error: 

    am335x/am335x_gpevm.c:341:5: error: 'gGpevmPinmuxData' undeclared here (not in a function)
    gGpevmPinmuxData,

    Which makes sense, as this extern pinmuxBoardCfg_t variable is now longer declared in the newly generated pinmux.h file. So, I solved this by simply adding back in all of those different board pinmux cfg variables:

    /* ========================================================================== */
    /* Global Variables */
    /* ========================================================================== */

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gGpevmPinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gEvmskPinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gBbPinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gBbbPinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gIceV1PinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool. */
    extern pinmuxBoardCfg_t gIceV2PinmuxData[];

    /** \brief Pinmux configuration data for the board. Auto-generated from
    Pinmux tool for IceV2, but with AMIC11x naming. Intended for
    manual deviation from IceV2, if applicable. */
    extern pinmuxBoardCfg_t gAMIC11xPinmuxData[];

    Great, now I can recompile the starterware project. But the board configuration has not changed, this is clear both by system behavior (original issue of no output on UART4) and using the Scripting Console tool mentioned above. 

    So... how can I most conclusively prove which board config set is being loaded for my project? Is there some step in the pinmux tool setup that I am missing? 

  • In reply to Nicholas Begley:

    I should say, my sys/bios cfg file includes this:

    /* Load the board package */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "icev2AM335x";

    So I believe it should be loading the correct board configuration.

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.