Hi,
At first, I'm using LM3S3748. but now, I 'm using LM3S3749 to use 3 UART chennals.
When I used the LM3S3748, UART communication is no problem. it is working well..
But, in case of LM3S3749, UART1 and UART2 are not work.
This is my code for UART2.
//*****************************************************************************//// uart_echo.c - Example for reading data from and writing data to the UART in// an interrupt driven fashion.//// Copyright (c) 2008-2010 Texas Instruments Incorporated. All rights reserved.// Software License Agreement// // Texas Instruments (TI) is supplying this software for use solely and// exclusively on TI's microcontroller products. The software is owned by// TI and/or its suppliers, and is protected under applicable copyright// laws. You may not combine this software with "viral" open-source// software in order to form a larger program.// // THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.// NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT// NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR// A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY// CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL// DAMAGES, FOR ANY REASON WHATSOEVER.// // This is part of revision 6734 of the EK-LM3S3748 Firmware Package.////*****************************************************************************
#include "inc/hw_ints.h"#include "inc/hw_memmap.h"#include "inc/hw_types.h"#include "driverlib/debug.h"#include "driverlib/gpio.h"#include "driverlib/interrupt.h"#include "driverlib/rom.h"#include "driverlib/sysctl.h"#include "driverlib/uart.h"#include "grlib/grlib.h"#include "drivers/formike128x128x16.h"
//*****************************************************************************////! \addtogroup example_list//! <h1>UART Echo (uart_echo)</h1>//!//! This example application utilizes the UART to echo text. The first UART//! (connected to the FTDI virtual serial port on the evaluation board) will be//! configured in 115,200 baud, 8-n-1 mode. All characters received on the//! UART are transmitted back to the UART.////*****************************************************************************
//*****************************************************************************//// Graphics context used to show text on the CSTN display.////*****************************************************************************tContext g_sContext;
//*****************************************************************************//// The error routine that is called if the driver library encounters an error.////*****************************************************************************#ifdef DEBUGvoid__error__(char *pcFilename, unsigned long ulLine){}#endif
//*****************************************************************************//// The UART interrupt handler.////*****************************************************************************voidUARTIntHandler_0(void){ unsigned long ulStatus;
// // Get the interrupt status. // ulStatus = ROM_UARTIntStatus(UART0_BASE, true);
// // Clear the asserted interrupts. // ROM_UARTIntClear(UART0_BASE, ulStatus);
// // Loop while there are characters in the receive FIFO. // while(ROM_UARTCharsAvail(UART0_BASE)) { // // Read the next character from the UART and write it back to the UART. // ROM_UARTCharPutNonBlocking(UART0_BASE, ROM_UARTCharGetNonBlocking(UART0_BASE)); }}
voidUARTIntHandler_2(void){ unsigned long ulStatus;
// // Get the interrupt status. // ulStatus = ROM_UARTIntStatus(UART2_BASE, true);
// // Clear the asserted interrupts. // ROM_UARTIntClear(UART2_BASE, ulStatus);
// // Loop while there are characters in the receive FIFO. // while(ROM_UARTCharsAvail(UART2_BASE)) { // // Read the next character from the UART and write it back to the UART. // ROM_UARTCharPutNonBlocking(UART2_BASE, ROM_UARTCharGetNonBlocking(UART2_BASE)); }}//*****************************************************************************//// Send a string to the UART.////*****************************************************************************voidUARTSend_0(const unsigned char *pucBuffer, unsigned long ulCount){ // // Loop while there are more characters to send. // while(ulCount--) { // // Write the next character to the UART. // ROM_UARTCharPutNonBlocking(UART0_BASE, *pucBuffer++); }}
voidUARTSend_2(const unsigned char *pucBuffer, unsigned long ulCount){ // // Loop while there are more characters to send. // while(ulCount--) { // // Write the next character to the UART. // ROM_UARTCharPutNonBlocking(UART2_BASE, *pucBuffer++); }}//*****************************************************************************//// This example demonstrates how to send a string of data to the UART.////*****************************************************************************intmain(void){ tRectangle sRect;
// // Set the clocking to run directly from the crystal. // ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_8MHZ);
// // Initialize the display driver. // Formike128x128x16Init();
// // Turn on the backlight. // Formike128x128x16BacklightOn();
// // Initialize the graphics context. // GrContextInit(&g_sContext, &g_sFormike128x128x16);
// // Fill the top 15 rows of the screen with blue to create the banner. // sRect.sXMin = 0; sRect.sYMin = 0; sRect.sXMax = GrContextDpyWidthGet(&g_sContext) - 1; sRect.sYMax = 14; GrContextForegroundSet(&g_sContext, ClrDarkBlue); GrRectFill(&g_sContext, &sRect);
// // Put a white box around the banner. // GrContextForegroundSet(&g_sContext, ClrWhite); GrRectDraw(&g_sContext, &sRect);
// // Put the application name in the middle of the banner. // GrContextFontSet(&g_sContext, &g_sFontFixed6x8); GrStringDrawCentered(&g_sContext, "uart_echo", -1, GrContextDpyWidthGet(&g_sContext) / 2, 7, 0);
// // Initialize the CSTN display and write status. // GrStringDraw(&g_sContext, "Port: Uart 0", -1, 12, 24, 0); GrStringDraw(&g_sContext, "Baud: 115,200 bps", -1, 12, 32, 0); GrStringDraw(&g_sContext, "Data: 8 Bit", -1, 12, 40, 0); GrStringDraw(&g_sContext, "Parity: None", -1, 12, 48, 0); GrStringDraw(&g_sContext, "Stop: 1 Bit", -1, 12, 56, 0);
// // Enable the peripherals used by this example. // ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART2); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
// // Enable processor interrupts. // IntMasterEnable();
// // Set GPIO A0 and A1 as UART pins. // ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1); ROM_GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1);
// // Configure the UART for 115,200, 8-N-1 operation. // ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 115200, (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE)); ROM_UARTConfigSetExpClk(UART2_BASE, ROM_SysCtlClockGet(), 115200, (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
// // Enable the UART interrupt. // ROM_IntEnable(INT_UART0); ROM_UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT); ROM_IntEnable(INT_UART2); ROM_UARTIntEnable(UART2_BASE, UART_INT_RX | UART_INT_RT);
// // Prompt for text to be entered. // /*UARTSend_0((unsigned char *)"Enter text: ", 12);*/ UARTSend_2((unsigned char *)"Enter text: ", 12);
// // Loop forever echoing data through the UART. // while(1) { }}
And, I add a interrupt service routain at startup_ewarm.c like as below,
__iar_program_start, // The reset handler NmiSR, // The NMI handler FaultISR, // The hard fault handler IntDefaultHandler, // The MPU fault handler IntDefaultHandler, // The bus fault handler IntDefaultHandler, // The usage fault handler 0, // Reserved 0, // Reserved 0, // Reserved 0, // Reserved IntDefaultHandler, // SVCall handler IntDefaultHandler, // Debug monitor handler 0, // Reserved IntDefaultHandler, // The PendSV handler IntDefaultHandler, // The SysTick handler IntDefaultHandler, // GPIO Port A IntDefaultHandler, // GPIO Port B IntDefaultHandler, // GPIO Port C IntDefaultHandler, // GPIO Port D IntDefaultHandler, // GPIO Port E UARTIntHandler_0, // UART0 Rx and Tx IntDefaultHandler, // UART1 Rx and Tx IntDefaultHandler, // SSI0 Rx and Tx IntDefaultHandler, // I2C0 Master and Slave IntDefaultHandler, // PWM Fault IntDefaultHandler, // PWM Generator 0 IntDefaultHandler, // PWM Generator 1 IntDefaultHandler, // PWM Generator 2 IntDefaultHandler, // Quadrature Encoder 0 IntDefaultHandler, // ADC Sequence 0 IntDefaultHandler, // ADC Sequence 1 IntDefaultHandler, // ADC Sequence 2 IntDefaultHandler, // ADC Sequence 3 IntDefaultHandler, // Watchdog timer IntDefaultHandler, // Timer 0 subtimer A IntDefaultHandler, // Timer 0 subtimer B IntDefaultHandler, // Timer 1 subtimer A IntDefaultHandler, // Timer 1 subtimer B IntDefaultHandler, // Timer 2 subtimer A IntDefaultHandler, // Timer 2 subtimer B IntDefaultHandler, // Analog Comparator 0 IntDefaultHandler, // Analog Comparator 1 IntDefaultHandler, // Analog Comparator 2 IntDefaultHandler, // System Control (PLL, OSC, BO) IntDefaultHandler, // FLASH Control IntDefaultHandler, // GPIO Port F IntDefaultHandler, // GPIO Port G IntDefaultHandler, // GPIO Port H UARTIntHandler_2, // UART2 Rx and Tx IntDefaultHandler, // SSI1 Rx and Tx IntDefaultHandler, // Timer 3 subtimer A IntDefaultHandler, // Timer 3 subtimer B IntDefaultHandler, // I2C1 Master and Slave IntDefaultHandler, // Quadrature Encoder 1 IntDefaultHandler, // CAN0 IntDefaultHandler, // CAN1 IntDefaultHandler, // CAN2 IntDefaultHandler, // Ethernet IntDefaultHandler, // Hibernate IntDefaultHandler, // USB0 IntDefaultHandler, // PWM Generator 3 IntDefaultHandler, // uDMA Software Transfer IntDefaultHandler // uDMA Error
But, UART2 is not working. There is not any output data in tx pin.
Is there some mistake to use UART2 in my code?
if it need to more modify or some specific setting, Could you advise me?
UART1 and UART2 is changed the pin from LM3S3748. I don't know that it is related with this symptom.
Pleasee review and advice
Thank you.
Penny,
I do not see any issues with your code. How are you testing the functionality of UART2?
Regards,
Alex
On this MCU Uart_0 on Port_A defaults into Uart Mode - this is not the case for the other two Uarts! You place Port_D into Uart mode by placing "1s" into bit positions (0,1) of GPIO Port_D's: GPIOAFSEL Register. Because this was "automatic" for Port_A you were lured into thinking that the same process would work for Port_D and others - which as you've discovered - is not the case.
cb1,
That's exactly what this call is for:
Penny56595ROM_GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1);
Whoops - sorry about that - thank you for the correction, Alex. (Started my answering post before yours - knew that his MCU defaulted into Uart mode on Uart0 - not 2 other Uart Ports - that's my story & sticking to it.) Will re-read StellarisWare function so as not to repeat mistake of judgement...
Still bothered as nothing concrete "jumps out." Unclear if you succeeded in getting the 2nd Uart to work on your 3S3748 - in other words - have you ever gotten two Uarts working with your original 3S3748? Trying to see if your Uart issue really is confined "just" to the new 3S3749 MCU.
Couple of long-shots - in case no others find & better diagnose:
a) Have you included the added entry required w/in: startup_ewarm? extern void UARTIntHandler_2(void);
b) Perhaps your rather unusual, "back to back" calls to slightly different: ROM_UARTConfigSetExpClk() (one for Uart_0, 2nd for Uart_2) causes some disturbance. As you report no Uart2 output data - suggest that you comment out this command for Uart_0 - and just attempt the operation upon Uart_2.
c) You may speed test/verify by (at least temporarily) not using interrupts. If you follow these forum thread guidelines - report back in some detail - I will provide simple, non-interrupt Stellaris code to run the Uart. (at least eliminates interrupt issues from your battle) (just temporary - to eliminate variables)
TI should note that both current datasheets (3S3748 & 3749) make 3 mentions of Register GPIOPCTL - which I don't believe is correct for either of these class MCUs. (and there is no GPIOPCTL Register included w/in the GPIO Register listing/inventory)
This must be your own pcb - how certain are you that routings are correct and that signals are at proper voltage levels. (you cannot safely connect PC to MCU's Uart without RS232/485 line drivers installed & operational.
As always - the more data you provide the better our diagnosis. Have you scoped Uart2's TX pin - helpful to know how you came to "no output" conclusion. You must have more than one of these custom pcbs - repeat the test across several and report. (we are assuming perfectly installed/functioning hardware - but the extra Uart may have routing and/or connection issues... (he/she who assumes...)
Alex,
Thank you for your answer.
Test way 1>
I test the UART2 communication with PC via EKI-LM3S811's virtual comm-port.
LM3S3749 is adding on own board, and my pc has not com-port.
LM3S3749's UART Rx and Tx are connected to virtual comm-port via EKI-LM3S811's UART Rx and Tx pins.
Test way 2>
Open status theLM3S3749's UART Tx pin.
And, I check the scope waveform.
In case of UART0, I can check the waveform of data output.
But, UART2 is not shown any waveform.
If there is some problem in my test way, please let me know.
In case of UART0, test result is good using both Test way 1 and Test way 2.
Thank you and best regards,
Penny.
Find no answer nor comment to troubleshooting procedures (a) & (b) included in last post. (1 above your most recent (Tue, May 1) Have additional ideas/methods for you to try - however time/energy is limited and reserve for those who do respond. If you don't understand my instructions (a & b, above) I will re-write in more detail - your last post provides no idea if you have understood, or disagree, or maybe missed those suggestions... We have no response to the question of number of prototype pcbs built. Single boards always are harder, take longer to test/verify than 2 or 3 protos - which enable quick/easy "A to B" comparison...
One quick basic - are you absolutely sure that you are probing at the Uart2 TX pin? Have you ohmed it out from MCU to your edge connector? If this proves true - then makes sense to see if this pin is shorted to VDD or Gnd or to neighbor pin.
Cb1,
Penny > Yes, I include the like this. You can check in my 1st post.
Penny > I already tested this way. I remained the clock setting for UART2 only. The result is same as before.
Penny> I tested using UARTprinf() without interrupt handler. The result is same as before too. If you have another test way, Could you let me know?
cb1- We have no response to the question of number of prototype pcbs built. Single boards always are harder, take longer to test/verify than 2 or 3 protos - which enable quick/easy "A to B" comparison... And - are you absolutely sure that you are probing at the Uart2 TX pin? Have you ohmed it out from MCU to your edge connector?
We have no response to the question of number of prototype pcbs built. Single boards always are harder, take longer to test/verify than 2 or 3 protos - which enable quick/easy "A to B" comparison...
And - are you absolutely sure that you are probing at the Uart2 TX pin? Have you ohmed it out from MCU to your edge connector?
While always unlikely - we've bumped against 100's of "open/shorted/mis-routed" pcb traces - and almost every time client swore, "Oh no - we checked!" Neither TI Alex nor I can yet find code error (to be fair to Alex I've looked longer/harder) - 2nd board repeating your Uart issue would build far better case for MCU fault - usual to always blame individual - never the IC. (and that IS the case 99+% of the time)
Thank you for yoru answer.
I tested the port function as general output port instead of UART2.(GPIO_D, Pin_0, Pin_1)
It is my test code.
intmain(void){ /*tRectangle sRect;*/
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1); GPIOPadConfigSet(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1, GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD_WPU);
// // Loop forever echoing data through the UART. // while(1) { GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1, GPIO_PIN_0|GPIO_PIN_1); SysCtlDelay(400000); GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1, 0); SysCtlDelay(400000); }}
And, the result is good, the ports are toggling well, please refer to below picture.
It is waveform of this test.(GPIO_D, Pin_0, Pin_1)
Yellow - GPIOD Pin_0 // Blue - GPIO Pin_1
Maybe, The PCB seems to be decent depending on this result.
BR,
Today I have read the code in your first post - seems OK, but you forgot to enable UART2 with the function call ROM_UARTEnable(UART2_BASE); also it is recommended, as is stated in the reference manual - before making a setting in internal registers (baud rate and/or others) to disable the UART first, make changes and then enable it.
Petrei
@Petrei: Wow - potentially put this reporter to shame - again!
However - function "ROM_UARTEnable()" was not neglected only w/in set-up for Uart_2 - my search of initial post fails to find it for Uart_0 as well - causing some doubt about its necessity. Best test is for original poster (OP) to add that code and try/report... (and I will check Uart code on our M4F to see if that function was "swallowed" by a newer, more encompassing one...)
As I stated in my 1st - answering post - as that MCU "defaults" into Uart mode for Uart_0 - that function may have been auto-included (if that's even possible) which "sets us up" for trouble when addressing non default Uart ports...
@cb1_mobile: This wasn't addressed to put someone to shame - just could be a small mistake... But you are right, only OP could to solve this, and the best thing is to investigate first the UART2 registers settings and tell us the result...
Petrei.
@Petrei: English is a strange language - use of "shame" was not meant to show displeasure w/you or the comment - but to concede your point - and to acknowledge another superior forum contribution by you. Good job Petrei! TI guys/gals do great job - but we outsiders do provide some value - at minimum we lessen mind-numbing wear/tear upon TI staff. (complaint of mine/others - too often staff avoid (imho) proper enforcement of "how to ask a question" guideline. If everyone "breaks the law" - then that law becomes meaningless - some enforcement appears beneficial!)
Back to the post - in my recent M4F code never once used ROM_UARTEnable() (or non rom variant). This works "still" for us (I checked) and appears to have worked for OP. (on his Uart_0) (and suspect that TI Alex would have noted/squawked if needed) Sense now that UARTEnable() has been swallowed by another function - possibly ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UARTx);
Will look this up next break and report...
*** Update: As just theorized: Function: UARTConfigSetExpClk() indeed swallowed (and now includes) the UARTEnable() function earlier referenced. So this mystery continues... I can't get poster to comment upon availability of 2nd, 3rd board - hate troubleshooting single board. If we can believe the scope and probe connections - unless TI has better analysis - starting to look now (more & more) like MCU issue... (beaten to death (yet not submission) by we outsiders...)