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.

uartSample example does not work when using uart1 instead of uart2



Hello,

I have an LCDK board and would like to connect it via UART lines to a Bluetooth Low Energy (BLE) evaluation module.

Firstly, I connected the LCDK to a Windows PC via the UART-USB connector andI ran the uartSample example from ...\pdk_C6748_2_0_0_0\biospsp_03_00_01_00\drivers\examples\evm6748\uart, which uses "uart2". The code works well.

Then, I modified the code to use "uart1" instead of "uart2" because I don't have a driver for the UART-USB port on the BLE evaluation module. I connected the LCDK's uart1 TX, RX pins on connector J15 to the correspondent RX, TX UART pins on the BLE kit. I also connected the GND pins.

I ran the uartSample for "uart1", but it doesn't work. The BLE kit can be programmed to send a greeting message over the serial port when pressing a button. The LCDK's uart1 receives the message successfully, but its TX is always high, it doesn't seem to send any data to the BLE module.I checked this with a digital oscilloscope, I can clearly see the trace on RX, triggered by a negative slope, but TX never does down.

Note: the BLE module's UART lines are electrically compatible with the LCDK UART lines. I am using a BLE module based on a Texas Instrument BLE chip.

I am attaching my uartSample project 1018.uart1.zip.

Could someone please let me know what am I am doing wrong? Why the uart1 TX line does not send any data? The software does not notice any errors.

Thanks,

Mayela

  • Hi,

    Are you probing UART1  Rx & Tx after isolate the both BLE and LCDK boards or connected together ?

    We will check your attachment and let you know status.

  • Hi,

    Thanks for your post

    I guess, you must reensure the UART params configuration modified for UART1 for LCDK board and revalidate the same. You have to check for valid configuration for baudrate, HWI number, rx threshold mapped for UART 1 in the code and it needs to be tested in LCDK board seperately first and you can probe the appropriate UART1 Tx. & Rx. pins on the LCDK to check for valid UART 1 signal sothat, you could narrow down the issue whether it belongs to LCDK board through probing the corresponding pins. Also, you could ensure & test the code you modified for UART1 for the LCDK board doesn't have any issues. By this way, you can validate your custom code written for UART1 is fine or not.

    You could also test the demo code to demonstrate the UART driver functionality works for UART1 modified code and you could test the sample string transmitted via UART interface.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------
    Please click the Verify Answer button on this post if it answers your question.
    -------------------------------------------------------------------------------------------------------
  • Hi Titus,

    Thanks for your prompt reply.

    I have probed TX under both conditions. I don’t see any change in either, it remains high. On the other hand, LCDK’s RX (boards connected) gets the signal from the BLE board and the packet is printed on the Code Composer console correctly when I debug the code attached. So, the UART’s on both boards are using the same parameters, baudrate, stop bit, byte length, no parity, no flow control, etc. I have successfully tested the UART in the BLE module independently, using a UART to USB converter included in the board and connecting to a PC. Also, I had no problems when testing UART2 on the LCDK board, using the original uartSample code and the UART-USB port connected to a PC.

    In order to access UART1’s TX and RX pins on the LCDK via connector J15, I shortcircuited the two terminals of the unpopulated resistors R206 and R209.

    Kind regards,

    Mayela

  • Hi Sivaraj,

    I suspect that the UART parameters, set in function user_uart_init(), are OK, since I am getting the data from the BLE board to the LCDK board correctly. I am not sure about the HWI number, I am preserving the same number as for UART2 in the original demo code (NB: uartSample is the DEMO code for UART driver provided by your employer). Of course, there is an issue with the LCDK board and demo code when UART1 is used instead of UART2, but I don’t know what it is, hence my question in the original post.

    I realised that parameter deviceId passed to GIO.addDeviceMeta() has to be different to the value of 2 for “\uart2” in the demo code .cfg file when using “\uart1”. My guess was to set deviceId to 1 for “\uart1”, and it seems to be correct since I am getting the data from the BLE module right. I wonder if there is a table in the documentation with the ID for each I/O device in the LCDK. I checked the manuals and the forum but could not find any.

    Regards,

    Mayela

  • Have you checked the UART pinmux function configureUart() for the platform? Source is here:

    platforms\evm6748\src\uart_evmInit.c

    You will probably have to clone configureUart(), modify it UART1, and rebuild the platform library. Or just pull in uart_evmInit.c code into a local module in your build.

    No idea why Rx would work at all without the proper pinmux.

  • Hi Norman,

    Thank you very much for your input. Following your suggestion, I modified the code in uart_evmInit.c. However, it does not work yet. I wonder if there are other hardcoded registers for UART2 in the example that should be changed.

    /*
     * uart_evmInit.c
     *
     * This file contains UART application related EVM (platform) specific routines
     * implementation. 
     * This is part of the EVM Initialization library (evmInit) which contains pinmux
     * enabling routines for peripherals used by the application, and may contain 
     * related device pre-driver initialization routines.
     *
     * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
     *
     *
     *  Redistribution and use in source and binary forms, with or without
     *  modification, are permitted provided that the following conditions
     *  are met:
     *
     *    Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     *    Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the
     *    distribution.
     *
     *    Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
     *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
     *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
     *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
     *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
     *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
     *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
     *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
     *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
     *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
     *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     *
    */
    
    /**
     *  \file   uart_evmInit.c
     *
     *  \brief  This file contains the board specific code for enabling the use of
     *          uart driver.
     *
     *  (C) Copyright 2009, Texas Instruments, Inc
     *
     */
    
    #include <xdc/std.h>
    #include <xdc/runtime/Log.h>
    #include <ti/sysbios/io/iom.h>
    #include <ti/sysbios/family/c64p/EventCombiner.h>
    
    #include <platforms/evm6748/Uart_evmInit.h>
    #include <cslr/cslr_syscfg0_C6748.h>
    #include <cslr/soc_C6748.h>
    
    #define PINMUX3_UART1_ENABLE_PINMUX0       0x00440000u
    #define PINMUX3_UART1_ENABLE_PINMUX4       0x22000000u
    
    #ifdef KICK_REG_ENABLE  
    
    /* Address of the KICK0 and KICK1 register                                    */
    #define KICK0                   (*((volatile Uint32 *)(0x01C14038u)))
    #define KICK1                   (*((volatile Uint32 *)(0x01C1403Cu)))
    
    /* Unlock/Lock code for KICK0 and KICK1 register                              */
    #define KICK0_UNLOCK_CODE       0x83E70B13u
    #define KICK1_UNLOCK_CODE       0x95A4F1E0u
    #endif
    
    void configureUart(void)
    {
        CSL_SyscfgRegsOvly syscfgRegs = (CSL_SyscfgRegsOvly)CSL_SYSCFG_0_REGS;    
        Uint32 savePinmux0 = 0;
        Uint32 savePinmux4 = 0;
        
    #ifdef KICK_REG_ENABLE      
        /* Unlock BOOTCFG module before pinmux configuration                      */
        KICK0 = KICK0_UNLOCK_CODE;
        KICK1 = KICK1_UNLOCK_CODE;
    #endif
    
        /* enable the pinmux registers for Uart                                   */
        savePinmux0 = (syscfgRegs->PINMUX0 &
                      ~(CSL_SYSCFG_PINMUX0_PINMUX0_23_20_MASK |
                    	CSL_SYSCFG_PINMUX0_PINMUX0_19_16_MASK));
        syscfgRegs->PINMUX0 = (PINMUX3_UART1_ENABLE_PINMUX0 | savePinmux0);
        
        savePinmux4 = (syscfgRegs->PINMUX4 &
                      ~(CSL_SYSCFG_PINMUX4_PINMUX4_31_28_MASK |
                    	CSL_SYSCFG_PINMUX4_PINMUX4_27_24_MASK));
        syscfgRegs->PINMUX4 = (PINMUX3_UART1_ENABLE_PINMUX4 | savePinmux4);
    }
    

    Cheers,

    Mayela

  • I can't see any other hard-coded values. The other HW values are dependent on the the device ID, which you have already set to 1 in the uartSample.cfg file.

    Double check that you using your changed  uart_evmInit.c. Maybe try renaming the function configureUart() just to make sure. That way, the linker will complain. Also, I'd skip muxing in RTS and CTS unless you really have them connected. Your pinmux values look correct.

    Perhaps you should try testing UART1 against a PC RS232 port. You'll need a level translator from logic levels to RS232 levels. You can also use a serial to USB adaptor as long as it supports logic level instead of RS232 levels.

  • Hi Norman,

    You are absolutely right. UART1 was still not working after the changes in the MUX configuration because I thought that a simple "Clean Project" and "Rebuild" would also rebuild the platform's code, but I was wrong. Instead of rebuilding the platform library, I opted for having a local copy of configureUart(). UART1 works now!

    Many thanks for your help.

    All the best,

    Mayela

  • Hi Norman,

    Thanks for your support on E2E forums.

    We really appreciate your sincere efforts on community forum and your valuable suggestion on E2E threads would also help others in providing solution to their problems.

    Thanks again for your inputs.

    Regards,
    Sivaraj K