Connecting GPS receiver to UART7 (case LM4F120 Stellaris LaunchPad Evaluation Kit)

Pentti:

I would solve the debug problem first. Make sure the crystal frequency is set correctly in the DEBUG section of Properties. You can also "slow down" the JTAG by clicking on the Stellaris_LM...ccxml file in the compiler window -- going to the advanced tab -- clicking on the CORTEX item (last in tree) then setting the speed there -- mine is set to 1000000 (1MHz) -- I have set it to 600000 on other boards due to speed issues.

Test LMFlash if nothing else works -- the usual. Try reading the memory first.

I notice it is a RIGOL scope -- I have been debating (with myself) the purchase of the 100MHz version -- is it satisfactory for this type of work generally?

The there is always the reboot -- had to do that yesterday when I hung up the USB in the PC.

I changed clock speed from 8 to 1 MHz. But it didn't help. Again i got the error messge : Error connecting to the target: Frequency is out of range. Then i tried to flash some code, but got again an error message : *ERROR blaab blaab. Just see the picture :

Pushing Both of buttons (Program and Hardware Reset) produced error message.After that i took my spare part stellaris launchpad and that worked. At least i managed to debug some code. Now i am thinking that my Stellaris Board nr 1 is out of order. It is broken or damaged seriously because of trying to connect gps's tx signal to not correct way configured input pin.

So how to adapt gps's cmos output signal with stellaris board's TTL level input pin.

Yes i have RIGOL DS1052E 50MHz/1GSa/s oscilloscope and i have not used it very often, but it is enough for measuring serial mode data and signal levels.

Pentti:

You are confusing three issues together...

The LMFlash clockspeed is set by choosing the Launchpad to 16MHz -- and it should stay there.

The Properties Debug -- that should be set to 16 MHz

The Steallris...xml file is where you can set a lower speed than the 1MHz JTAG speed.

hth

And the Scope???? :-) I gather it is more than sufficient for this serial work. But, would the 100MHz be better for more general CORTEX work?

1

I think that 100 MHz oscilloscope is not enough for serial work where you measure the data/command/address bus signals. But that is Cortex microprocessor world where you physically can see and measure the core microprocessor's signals. But in LauchPad world where you are able to measure only outside world signals connected to microcontroller's pins, is not so critical. But USB is quite fast nowadays, that is 100 MHz oscilloscope enough any more?

2

My broken stellaris.

I found from LM Flash Programmer > Other Utilities > Debug Port Unlock and tried those two not very harmfull buttons (Furry, ... & Tempest ...) and miracle happened - Broken Stellaris Launchpad began to breath again. It is working again. Just don't know why debug port was locked.

But how to adapt gps's transmitter's CMOS level signal with Launchpad's TTL level RX input pin. I know that there is programmatically way to configure pull-up resistor at least to GPIO's input signal. But how to do that?

"Is your concern that the GPS chip is using a 1.8V interface?" No. GPS signal is 0 - 3 V and now launhapad is reading nmea data well. But when i echo received character via UART7/ U7Tx / PE1/ pin8 to the oscilloscope, data looks very messy. But i can see the correct signal behind noisy signal.  Here are the details of GPS receiver - not much :

http://www.servizi-elettronici.com/GPS/UPATCH100-SPECIFICHE.pdf

So the remaining problem is that output signal gets messy like this :

All malfunctions that happened was because of wrongly connected supply voltage on devices (= power supply for gps receiver, for oscilloscope, for computer that supplies launhpad). There was no ground level potential in none of the devices. Or was but they were in different voltage levels. Now i have plugged all devices into same voltage splitter and then splitter's plug into earthed 220 VAC (yes in USA 110 VAC). Now characters are received and re-transmitted without distortion in signals and interrupts occurs when have to occur. In malfunction situation D1 rgb-led glowed a litte bit.

Hi,

I'm currently adapting the CC4000 NMEA Message Parser for use with Stellaris. The parser is located in the UART ISR at the moment.

My Problem is that I only get an interrupt once after receiving a '$' from the GPS and Never again.

I would be glad to See your UART initialization Code and ISR.

I will See to Post Message parser later, but I will have to shrink it Down first so others were able to reproduce the problem. By the Way; my GPS is the GlobalTop PA6C in my C3ii booster.

aBUGSworstnightmare

Here is the quick and dirty code that i have copied here and there and made some changes. :

/// Start

#define UART_NUM = 7



#define UART_BASE UART7_BASE
#define INT_UART INT_UART7
#define PERIPHERAL_UART SYSCTL_PERIPH_UART7
#define PERIPHERAL_GPIO SYSCTL_PERIPH_GPIOE
#define GPIO_BASE GPIO_PORTE_BASE
#define GPIO_PINS (GPIO_PIN_0 | GPIO_PIN_1)
#define PCTL_PINS (GPIO_PCTL_PE0_U7RX | GPIO_PCTL_PE1_U7TX )


/*
#define UART_BASE UART3_BASE
#define INT_UART INT_UART3
#define PERIPHERAL_UART SYSCTL_PERIPH_UART3
#define PERIPHERAL_GPIO SYSCTL_PERIPH_GPIOC
#define GPIO_BASE GPIO_PORTC_BASE
#define GPIO_PINS (GPIO_PIN_6 | GPIO_PIN_7)
#define PCTL_PINS (GPIO_PCTL_PC6_U3RX | GPIO_PCTL_PC7_U3TX )
*/

#include "grlib/inc/hw_ints.h"
#include "grlib/inc/hw_memmap.h"
#include "grlib/inc/hw_types.h"
#include "grlib/inc/hw_gpio.h"

#include "driverlib/debug.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"
#include "driverlib/interrupt.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"


#undef GPIO_LOCK_KEY
#include "grlib/inc/lm4f120h5qr.h"



#ifdef DEBUG
void
__error__(char *pcFilename, unsigned long ulLine)
{
}
#endif

unsigned long ulStatus;
unsigned char c;

void
UARTIntHandler(void)
{
    //unsigned long ulStatus;
    //unsigned char c;
    //
    // Get the interrrupt status.
    //
    ulStatus = ROM_UARTIntStatus(UART_BASE, true);

    //
    // Clear the asserted interrupts.
    //
    ROM_UARTIntClear(UART_BASE, ulStatus);

    //
    // Loop while there are characters in the receive FIFO.
    //
    while(ROM_UARTCharsAvail(UART_BASE))
    {

     //
      // Read the next character from the UART and write it back to the UART.
      //
      //ROM_UARTCharPutNonBlocking(UART_BASE,ROM_UARTCharGetNonBlocking(UART_BASE));
        c = (unsigned char)ROM_UARTCharGetNonBlocking(UART_BASE);
        //c = c >> 4;
        UARTCharPut(UART0_BASE, c);
        ROM_UARTCharPutNonBlocking(UART_BASE, c);
    }
}

//Not used but not removed
void
UARTSend(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(UART_BASE, *pucBuffer++);
    }
}

int
main(void)
{
    //
    // Set the clocking to run directly from the crystal, this setup gives a 16MHz clock
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);

    //Start Initialize UART0
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    UARTConfigSetExpClk(UART0_BASE, SysCtlClockGet(), 9600,
                        (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                         UART_CONFIG_PAR_NONE));
    UARTCharPut(UART0_BASE, '!');
    //End Initializing UART0
    //
    // Enable the peripherals used by this example.
    //
    ROM_SysCtlPeripheralEnable(PERIPHERAL_UART);
    ROM_SysCtlPeripheralEnable(PERIPHERAL_GPIO);
    //
    // Set up I/O pins for chosen port
    //
    ROM_GPIOPinTypeUART(GPIO_BASE, GPIO_PINS);
    //
    // Enable processor interrupts.
    //
    ROM_IntMasterEnable();
    //

    //  more configuration for uarts1/2 - this is in fact the only extra code needed for UART1/2
//#ifdef UART_NUM != 0
    HWREG(GPIO_BASE + GPIO_O_PCTL) = PCTL_PINS ;
//#endif
    //
    // Configure the UART for 9600, 8-N-1 operation.
    //
    ROM_UARTConfigSetExpClk(UART_BASE, ROM_SysCtlClockGet(), 9600, /*115200,*/
                            (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_PAR_NONE));

    UARTFIFOLevelSet(UART_BASE, UART_FIFO_TX1_8, UART_FIFO_RX1_8);

    //
    // Enable the UART interrupt.
    //

   // this line below was added to replace the code in startup.c

   //
    UARTIntRegister(UART_BASE,UARTIntHandler);
    ROM_IntEnable(INT_UART);
    ROM_UARTIntEnable(UART_BASE, UART_INT_RX | UART_INT_RT);
    //
    // Prompt for text to be entered.
    //
    //while (1) {
    //    UARTSend((unsigned char *)"\033[2JEnter text: ", 16);
    //    SysCtlDelay(1000);
    //}
    //
    // Loop forever echoing data through the UART.
    //

    //c = 'N';
    while(true)
    {
        //c = (unsigned char)ROM_UARTCharGetNonBlocking(UART_BASE);
        //ROM_UARTCharPutNonBlocking(UART_BASE, c);
        //SysCtlDelay(1000);
    }
}

Remember to add UARTIntHandler to the startup code on uart7. uart0 just echoes charecters to the pc's virtual com port that putty uses.

So uart7 uses both tx- and rx-port and uart0 uses only tx-port.

/// End

Hi Pentti,

thanks for posting your code here! Looks like a modified version of UART echo.

I found the root course for my UART interrupt problem! It was a misplaced breakpoint that  'confused' my GPS message parser. As fas as I can tell at the moment it seems to work now as expected.

Will need some more testing though. If your interested in, the source code will be linked on the C3ii project page when it's finished.

aBUGSworstnightmare

Ok, i stay tuned on your project. My gps project is to wirelesly telegraph with morse characters average speed, used time and travelled distance with stellaris launchpad tied on my bicycling helmet. My second hobby is bicycling and sometimes on the road it is better to listen numbers than read numbers from gps device's display.

Stellaris on the video :

http://www.youtube.com/watch?NR=1&v=Hb9VNauBOAI