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.

Very Fast UART in VirtualCOM

Other Parts Discussed in Thread: EK-TM4C123GXL

Hello all.
I am implementing more features in my Stellaris Launchpad board (I am using the last Stellarisware installation package for LM4F devices, not Tivaware) and I wanted to stream ADC data as fast as I could to a interface app in a Windows PC. Starting with something simple, I was using UART0 with the UARTStdioInit(0); instruction to get it working (being the baudrate as default 115200).

//
// Initialize the UART.
//
ROM_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOA);
ROM_GPIOPinConfigure (GPIO_PA0_U0RX);
ROM_GPIOPinConfigure (GPIO_PA1_U0TX);
ROM_GPIOPinTypeUART (GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
UARTStdioInit(0);



After that I called the function:
UARTStdioConfig(ulPortNum,1000000 , MAP_SysCtlClockGet());
to set up 1Mbps, which works fine for short strings via UARTprintf("string to send");

After that I tried to send an array of 1100 bytes of hexadecimal data, and that is my problem right now. I am using the function:

UARTwrite((uint8_t *)buf_msx,1100); which calls: MAP_UARTCharPut(g_ulBase, pcBuf[uIdx]);

So to my understanding, this function shouldn't return until all the data is correctly sent.

When I read the data in an hexadecimal terminal, I get only about 600 bytes of the 1100 expected.

---------------------------------------------------------------------------------------------------------------------------


Then I have tried to setup a udma (channel9 for UART0 Tx) with the same results.

UARTDMAEnable(UART0_BASE, UART_DMA_TX);

UARTEnable(UART0_BASE);

IntEnable(INT_UART0); //Enable the UART interrupt.

//uDMA initialization
// Enable uDMA peripheral
SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);

uDMAEnable();

// Set uDMA control table
uDMAControlBaseSet(ucControlTable);

//choose 9 Channel to UART0TX
uDMAChannelAssign(UDMA_CH9_UART0TX);

uDMAChannelAttributeDisable(9, UDMA_ATTR_ALL);

uDMAChannelControlSet(9 | UDMA_PRI_SELECT,
UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE | UDMA_ARB_4);

uDMAChannelTransferSet(9 | UDMA_PRI_SELECT, UDMA_MODE_BASIC, buf_msx,
(void *) (UART0_BASE + UART_O_DR), 1100/2);

uDMAChannelEnable(9);



....
....
....

//In the interrupt the rest and enable again
uDMAChannelTransferSet(9 | UDMA_PRI_SELECT, UDMA_MODE_BASIC, buf_msx,
(void *) (UART0_BASE + UART_O_DR), 1100/2);

uDMAChannelEnable(9);


If I split up the amount of Dma sent data in 16byte size packets in the interrupt, I get like 900 bytes, but not the whole frame.


Is there anything I am doing wrong?
Which is the max speed for the VirtualCOM?
Is there any limitation in size?
Is there any example for this?

Thank you

  • Haven't an exact answer - perhaps this approach may assist...

    Sense is that you had success w/ UARTStdio() while operating @ 115200.  Is this correct?

    Speed then raised to 1000000 - and transfer was incomplete.  The nature of that, "failure to complete" may shed beneficial light:

    a) you report receiving ~600 out of 1100 bytes expected - were those missing bytes not transmitted - or instead received in error?

    b) you then move to UDMA mode - and yield rises to ~900/1100.  Again - bytes missed or received in error?

    1) Would it make sense to incrementally increase your transfer speed - and determine just where system breaks down?  (i.e. 2 "hops" up to 1M speed)

    2) Is your Windows PC proven/confirmed to transfer at that high speed - and at a full 1100 byte transfer - recently?  And using the exact same USB-Serial Converter device and/or cable.

    3) If a scope is available - may be useful to "seed" the expected bytes just before & intruding into "breakdown" w/0x55 - and observe their timing & shape & and any possible "disturbance" in the transfer sequence.  (i.e. perhaps some data dropout or delay can be noted)

    4) Unstated is the distance (cable length) - at high speeds - and w/questionable cables/converters - reality of physics may intrude...

  • Thank you for your answer cb1_mobile, but actually that is not the flow.

    a) I have had success w/ UARTStdio() while operating @ 115200, then I used: 

    b) UARTStdioConfig(ulPortNum, 1000000, MAP_SysCtlClockGet());   with success as well (with short messages).

    c)  After that I tried to send a 1100 message, and then the error appears.

    d) I have tested my USB2.0 and USB3.0 Windows7 PC ports with an arduino DUE at 40Msps throughput with no error at all!!

    I think the error is related to something with the buffer of the UART, I have found some cuts now with long messages using UARTPRINTF on UART0, which before setting other UART devices (UART0, UART3 and UART4)  didn't show!!

  • PAk SY said:
    at 40Msps throughput with no error at all!!

    Msps you list is not normal/customary for UART Speed characterization.  (sounds more like an ADC spec) 

    What baud rate could you maintain w/that set-up?  Was the exact same connection cable & USB converter in use - during that earlier test?

    You don't explain the nature of past, "missing bytes."  "Cuts" while clear to you - not so much to me/others.  Is this missing data not transmitted - or not received - or received in error?  And - how do you resolve between "not transmitted" vs. "not received."  (if either was the case)

  • You are absolutely right.I am sorry for the misunderstandings but English is not my mother tongue.

    The scenario is that I am only transmitting from the stellaris to the PC a known sequence like 

    buffer_tx[0]=0; buffer_tx[1]=1;buffer_tx[2]=2;.....etc

    When I said Msps, I meant 40Mbaud/s (pretty high indeed!!)

    I was using the Native USB port of the Arduino DUE, which is connected directly to the SAM3X chip included in that board. The USB cable is the same, and all the data is received correctly on the windows app.


    When I said "missing bytes" and "cuts", what I wanted to say is that the beggining of the message is received correctly in the PC, then after some bytes (150 aprox.) I start to see some bytes are not consecutive (as expected).At the end, when a whole frame is received, I only get those 600 bytes, not the 1100 bytes "supposedly" sent.

    Thank you again


  • No one asks/seeks your sorrow - and I would/could not have guessed your non "mother tongue."  (nor your mastery of english, "idiom.")  You're doing very well...

    As I now understand - brand "A" MCU's USB port direct connects to PC's USB port.  Is this correct?

    Then - for your Stellaris evaluation (I missed - or we don't know - which MCU) do you interpose a UART to USB converter between Stellaris and your PC?  And - this device is not, "in play/use" when you tested brand "A" - is this correct?  Should this be the case - is not this "converter" a possible cause?  (or contributor)

    I can't identify what could cause ~150 "high speed" bytes to transfer correctly - and then start to "stumble."  Seems more likely that you'd see such condition around the buffer fill/refill size (16 bytes my assumption).  Is there any other buffering w/in your code that approaches this ~150 length? 

    And - have you tried at rates above 115K - but less than the troublesome 1M?  If so - please describe those results...

  • cb1_mobile said:
    As I now understand - brand "A" MCU's USB port direct connects to PC's USB port.  Is this correct?

    Yes it is. This brand "A" MCU, intalls a driver on Windows which creates a Virtual COM Uart....just like the Debug port of the Stellaris Launchpad.

    cb1_mobile said:
    Then - for your Stellaris evaluation (I missed - or we don't know - which MCU) do you interpose a UART to USB converter between Stellaris and your PC?

    I use a direct USB cable, using the virtualcom, so then the ICDI - debug driver provided by TI, to do the same that I did with the Arduino Due board. Just trying to get data really fast from the MCU to the PC.

    cb1_mobile said:
     Seems more likely that you'd see such condition around the buffer fill/refill size (16 bytes my assumption).  Is there any other buffering w/in your code that approaches this ~150 length? 

    There is not other buffering, in fact I was using UARTprintf(), which just prints strings on the UART0 port.

    cb1_mobile said:
    And - have you tried at rates above 115K - but less than the troublesome 1M?  If so - please describe those results...

    EDITED: I run the test at different speeds (post below)

    Not yet, but is not supposed that using UARTprintf, UARTwrite or UARTCharPut , I should get all the data transfered no matter what?

    In fact UARTCharPut source code shows that it has a while for waiting (code in driverlib/uart.c file). UARTCharPutNonBlocking may return if there is not space available.

    I don't understand this behavior.

  • cb1_mobile said:
    And - have you tried at rates above 115K - but less than the troublesome 1M?  If so - please describe those results...


    I have done it using the code:

     UARTwrite((uint8_t *)buf_msx,1038);


    And what I get is:

    - At  115200   - All 1038 bytes - so OK

    - At  230400   - All 1038 bytes - so OK 

    - At  460800   - 1011 - 1024   bytes 

    - At  500000   - 990 - 1000     bytes 

    - At  800000   - 721- 765        bytes 

    - At 1000000   - 600- 650      bytes 

    I am using exactly the same USB port that I use when I connect the Arduino Due at 40,000,000 bps.

    Is it the clocking of Stellaris? Is it its buffer? 



  • Reread your 1st post - now know that yours is launchpad - which has 2 LX4F MCUs.  (one serves as ICDI)  And - it is possible (perhaps likely) that this 2nd MCU may be limiting the transfer speed.

    Believe that we should compare, "apples to apples" - and if brand "A" MCU offers HW MCU USB Port - without any such ICDI chip - then the comparison is not strictly the same.  And - for general debug/programming purposes - my belief is that 115Kbaud is sufficient - and may not have been optimized for transfer speed.  Does this analysis make sense to you - are you in agreement?

    Beyond this - the PC side drivers also impact transfer speed - and as these are different (one brand "A" - the other Stellaris) I believe that further complications have been introduced.   It may be that the brand "A" PC side driver runs faster and/or more efficiently. 

    And - you should review the "back of the datasheet" specs for UART (Stellaris) vs USB Port (other brand) - see if anything reveals...

    One final point - by scoping the UART output - you can note if any fall-off in transfer speed occurs.  (either due to added inter-character delays - or "pauses" introduced - which may indicate some weakness in the placement, access or unpacking of your buffer.

  • I think UARTprintf, UARTwrite or UARTCharPut don't do what they say.

    I was able to repeat the behavior of "lost data" at 115200bps by  sending a large string  (350 characters) in UARTprintf, and after that, a few instructions later sending another 400 byte string in a different UARTprintf. The same with UARTwrite.

    Both messages mix at the end. If the Uart hasn't finish to send the first one, then some data get lost.

    I think that UARTprintf, UARTwrite or UARTCharPut returns when the data is in the FIFO (or ready for the UART for sending),  the program continues running, even if the UART is free or not (has finished the transmission or not),soon another function tries to use the UART but only gets some free space at the end.... the bytes that got sent, the rest is lost!!

    Maybe some kind professional from TI could give us some light about this topic.

    Thank you




  • Our uartstdio.c files is built by default with software buffering turned off.  It then spins and polls using a lot of clock cycles.

    I'd suggesting adding UART_BUFFERED to the list of pre-defined symbols.  Also add the UARTStdioIntHandler to the interrupt table in the startup file.  This will enable a circular software buffer in the uartstdio.c file that can be as big as you define it to be.

    This should help if you think that the UART is being overrun.  It may be that at high speeds the software polling methods are not fast enough.

    Dexter

  • Stellaris Dexter said:
    Our uartstdio.c files is built by default with software buffering turned off

    Thanks for this - suspect many (to include this reporter) had missed!

    Poster reports similar, "large block xmsn" distress with: UARTprintf, UARTwrite and UARTCharPut - as well.  Might these continue this buffer OFF practice?

  • UARTwrite lives in uartstdio.c in utils and follows the same #ifdef UART_BUFFERED rules as UARTprintf

    UARTCharPut is polled it waits until the byte is transferred before returning.  see UARTCharPutNonBlocking for the function that returns immediately after byte is put into the buffer not when it has been transmitted.  These functions live in driverlib\uart.c and are not affected by UART_BUFFERED either way.

    Dexter

  • @Dexter,

    Thanks for this. As always - appreciated. 

    Hope that op sees/reviews - and that something here improves his transfer rate

  • Stellaris Dexter said:

    UARTwrite lives in uartstdio.c in utils and follows the same #ifdef UART_BUFFERED rules as UARTprintf

    UARTCharPut is polled it waits until the byte is transferred before returning.  see UARTCharPutNonBlocking for the function that returns immediately after byte is put into the buffer not when it has been transmitted.  These functions live in driverlib\uart.c and are not affected by UART_BUFFERED either way.

    Dexter

    Thank you Dexter,  but then, why if I send two strings via two Uartprintf commands, one just after another, with a long strong (more than 300 characters) ,why the received strings are not complete?

    Shouldn't they be totally received whatever time it takes?

  • I conducted a test to verify correct operation.  I used the "hello" application from TivaWare for the EK-LM4F120XL (LaunchPad).  I added the first roughly 8600 characters of text from the Iliad to a C file and brought that into my project.  I then UARTprintf the entire 8600 character string.  Followed immediately by a second UARTprintf of just the last 600 characters or so.

    I did this at 115200, 230400 and 460800 bits per second.  All tests were completed without error and all of the text was transmitted as expected.

    I am using a saleae Logic 8 analyzer to read the ASCII on the line.  Again all the bytes appear and in the correct order from both UARTprintf statements.

    These tests were done in UART_BUFFERED mode off.  The default buffer size is much smaller than my 8600 bytes so the first UARTprintf overruns the buffer.  To do a buffered test we would need to drastically increase buffer size.

    Dexter

  • 8637.iliad.c
    char cIliad[] = "Provided by The Internet Classics Archive. "
    "See bottom for copyright. Available online at                                  "
    "    http://classics.mit.edu//Homer/iliad.html                                  "
    "                                                                               "
    "The Iliad                                                                      "
    "By Homer                                                                       "
    "                                                                               "
    "                                                                               "
    "Translated by Samuel Butler                                                    "
    "                                                                               "
    "----------------------------------------------------------------------         "
    "                                                                               "
    "BOOK I                                                                         "
    "                                                                               "
    "Sing, O goddess, the anger of Achilles son of Peleus, that brought             "
    "countless ills upon the Achaeans. Many a brave soul did it send hurrying       "
    "down to Hades, and many a hero did it yield a prey to dogs and vultures,       "
    "for so were the counsels of Jove fulfilled from the day on which the           "
    "son of Atreus, king of men, and great Achilles, first fell out with            "
    "one another.                                                                   "
    "                                                                               "
    "And which of the gods was it that set them on to quarrel? It was the           "
    "son of Jove and Leto; for he was angry with the king and sent a pestilence     "
    "upon the host to plague the people, because the son of Atreus had              "
    "dishonoured Chryses his priest. Now Chryses had come to the ships              "
    "of the Achaeans to free his daughter, and had brought with him a great         "
    "ransom: moreover he bore in his hand the sceptre of Apollo wreathed            "
    "with a suppliant's wreath and he besought the Achaeans, but most of            "
    "all the two sons of Atreus, who were their chiefs.                             "
    "                                                                               "
    "\"Sons of Atreus,\" he cried, \"and all other Achaeans, may the gods           "
    "who dwell in Olympus grant you to sack the city of Priam, and to reach         "
    "your homes in safety; but free my daughter, and accept a ransom for            "
    "her, in reverence to Apollo, son of Jove.\"                                    "
    "                                                                               "
    "On this the rest of the Achaeans with one voice were for respecting            "
    "the priest and taking the ransom that he offered; but not so Agamemnon,        "
    "who spoke fiercely to him and sent him roughly away. \"Old man,\" said         "
    "he, \"let me not find you tarrying about our ships, nor yet coming             "
    "hereafter. Your sceptre of the god and your wreath shall profit you            "
    "nothing. I will not free her. She shall grow old in my house at Argos          "
    "far from her own home, busying herself with her loom and visiting              "
    "my couch; so go, and do not provoke me or it shall be the worse for            "
    "you.\"                                                                         "
    "                                                                               "
    "The old man feared him and obeyed. Not a word he spoke, but went by            "
    "the shore of the sounding sea and prayed apart to King Apollo whom             "
    "lovely Leto had borne. \"Hear me,\" he cried, \"O god of the silver bow,       "
    "that protectest Chryse and holy Cilla and rulest Tenedos with thy              "
    "might, hear me oh thou of Sminthe. If I have ever decked your temple           "
    "with garlands, or burned your thigh-bones in fat of bulls or goats,            "
    "grant my prayer, and let your arrows avenge these my tears upon the            "
    "Danaans.\"                                                                     "
    "                                                                               "
    "Thus did he pray, and Apollo heard his prayer. He came down furious            "
    "from the summits of Olympus, with his bow and his quiver upon his              "
    "shoulder, and the arrows rattled on his back with the rage that trembled       "
    "within him. He sat himself down away from the ships with a face as             "
    "dark as night, and his silver bow rang death as he shot his arrow              "
    "in the midst of them. First he smote their mules and their hounds,             "
    "but presently he aimed his shafts at the people themselves, and all            "
    "day long the pyres of the dead were burning.                                   "
    "                                                                               "
    "For nine whole days he shot his arrows among the people, but upon              "
    "the tenth day Achilles called them in assembly- moved thereto by Juno,         "
    "who saw the Achaeans in their death-throes and had compassion upon             "
    "them. Then, when they were got together, he rose and spoke among them.         "
    "                                                                               "
    "\"Son of Atreus,\" said he, \"I deem that we should now turn roving home       "
    "if we would escape destruction, for we are being cut down by war and           "
    "pestilence at once. Let us ask some priest or prophet, or some reader          "
    "of dreams (for dreams, too, are of Jove) who can tell us why Phoebus           "
    "Apollo is so angry, and say whether it is for some vow that we have            "
    "broken, or hecatomb that we have not offered, and whether he will              "
    "accept the savour of lambs and goats without blemish, so as to take            "
    "away the plague from us.\"                                                     "
    "                                                                               "
    "With these words he sat down, and Calchas son of Thestor, wisest of            "
    "augurs, who knew things past present and to come, rose to speak. He            "
    "it was who had guided the Achaeans with their fleet to Ilius, through          "
    "the prophesyings with which Phoebus Apollo had inspired him. With              "
    "all sincerity and goodwill he addressed them thus:-                            "
    "                                                                               "
    "\"Achilles, loved of heaven, you bid me tell you about the anger of            "
    "King Apollo, I will therefore do so; but consider first and swear              "
    "that you will stand by me heartily in word and deed, for I know that           "
    "I shall offend one who rules the Argives with might, to whom all the           "
    "Achaeans are in subjection. A plain man cannot stand against the anger         "
    "of a king, who if he swallow his displeasure now, will yet nurse revenge       "
    "till he has wreaked it. Consider, therefore, whether or no you will            "
    "protect me.\"                                                                  "
    "                                                                               "
    "And Achilles answered, \"Fear not, but speak as it is borne in upon            "
    "you from heaven, for by Apollo, Calchas, to whom you pray, and whose           "
    "oracles you reveal to us, not a Danaan at our ships shall lay his              "
    "hand upon you, while I yet live to look upon the face of the earth-            "
    "no, not though you name Agamemnon himself, who is by far the foremost          "
    "of the Achaeans.\"                                                             "
    "                                                                               "
    "Thereon the seer spoke boldly. \"The god,\" he said, \"is angry neither        "
    "about vow nor hecatomb, but for his priest's sake, whom Agamemnon              "
    "has dishonoured, in that he would not free his daughter nor take a             "
    "ransom for her; therefore has he sent these evils upon us, and will            "
    "yet send others. He will not deliver the Danaans from this pestilence          "
    "till Agamemnon has restored the girl without fee or ransom to her              "
    "father, and has sent a holy hecatomb to Chryse. Thus we may perhaps            "
    "appease him.\"";
    

    2742.hello.c
    //*****************************************************************************
    //
    // hello.c - Simple hello world example.
    //
    // Copyright (c) 2012-2013 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 1.0 of the EK-TM4C123GXL Firmware Package.
    //
    //*****************************************************************************
    
    #include <stdint.h>
    #include <stdbool.h>
    #include "inc/hw_memmap.h"
    #include "inc/hw_types.h"
    #include "driverlib/debug.h"
    #include "driverlib/fpu.h"
    #include "driverlib/gpio.h"
    #include "driverlib/pin_map.h"
    #include "driverlib/rom.h"
    #include "driverlib/sysctl.h"
    #include "driverlib/uart.h"
    #include "utils/uartstdio.h"
    
    //*****************************************************************************
    //
    //! \addtogroup example_list
    //! <h1>Hello World (hello)</h1>
    //!
    //! A very simple ``hello world'' example.  It simply displays ``Hello World!''
    //! on the UART and is a starting point for more complicated applications.
    //!
    //! UART0, connected to the Virtual Serial Port and running at
    //! 115,200, 8-N-1, is used to display messages from this application.
    //
    //*****************************************************************************
    
    extern char cIliad[];
    
    //*****************************************************************************
    //
    // The error routine that is called if the driver library encounters an error.
    //
    //*****************************************************************************
    #ifdef DEBUG
    void
    __error__(char *pcFilename, uint32_t ui32Line)
    {
    }
    #endif
    
    //*****************************************************************************
    //
    // Configure the UART and its pins.  This must be called before UARTprintf().
    //
    //*****************************************************************************
    void
    ConfigureUART(void)
    {
        //
        // Enable the GPIO Peripheral used by the UART.
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    
        //
        // Enable UART0
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    
        //
        // Configure GPIO Pins for UART mode.
        //
        ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
        ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
        ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    
        //
        // Use the internal 16MHz oscillator as the UART clock source.
        //
        UARTClockSourceSet(UART0_BASE, UART_CLOCK_SYSTEM);
    
        //
        // Initialize the UART for console I/O.
        //
        UARTStdioConfig(0, 115200 * 4, SysCtlClockGet());
    }
    
    //*****************************************************************************
    //
    // Print "Hello World!" to the UART on the evaluation board.
    //
    //*****************************************************************************
    int
    main(void)
    {
        //volatile uint32_t ui32Loop;
    
        //
        // Enable lazy stacking for interrupt handlers.  This allows floating-point
        // instructions to be used within interrupt handlers, but at the expense of
        // extra stack usage.
        //
        ROM_FPULazyStackingEnable();
    
        //
        // Set the clocking to run directly from the crystal.
        //
        ROM_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ |
                           SYSCTL_OSC_MAIN);
    
        //
        // Enable the GPIO port that is used for the on-board LED.
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    
        //
        // Enable the GPIO pins for the LED (PF2 & PF3).
        //
        ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2);
    
        //
        // Initialize the UART.
        //
        ConfigureUART();
    
    //    GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_PIN_1, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);
    
        //
        // Hello!
        //
        UARTprintf(cIliad);
        UARTprintf(cIliad + 8000);
    
        //
        // We are finished.  Hang around doing nothing.
        //
        while(1)
        {
            //
            // Turn on the BLUE LED.
            //
            GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2);
    
            //
            // Delay for a bit.
            //
            SysCtlDelay(SysCtlClockGet() / 10 / 3);
    
            //
            // Turn off the BLUE LED.
            //
            GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0);
    
            //
            // Delay for a bit.
            //
            SysCtlDelay(SysCtlClockGet() / 10 / 3);
        }
    }
    

    My test files.  Add iliad.c to the hello project in TivaWare_C_Series-1.0\examples\boards\ek-tm4c123gxl\

    My other changes were to the baud rate in configure uart and also to the clocking of the UART.  I used system clock speed not the PIOSC.  PIOSC is 16 Mhz  Running at around 1Mbit should be possible with PIOSC but to eliminate that variable I used the System clock which is 50 Mhz in this case.

    Dexter

  • @Dexter,

    This is good stuff - thank you - (effort, method design) appreciated.

    While the Saleae Logic 8 is "reading" the ASCII on the line - poster described use of UART->USB converter - w/PC terminal program as final destination.  Thought here was that the entirety of the channel was under scrutiny - and MCU could not properly be judged as "sole" cause of data loss/limitations.  Might you comment?

    Assume that Logic 8 analyzer has buffer > 8600 chars - would you be good enough to describe how that content is viewed?  (one assumes "not" live - but via some "after the fact" data dump.)

    Again - your interest & keen efforts much appreciated...

     

  • Yes, the Logic8 samples the raw data stream at something like 4 Mhz (software selectable) it buffers up about 25 Million samples (again software selectable).  Then post processes the entire data stream and interprets ASCII from the bits on the bus.  This is a great debug tool with great software for most digital embedded communications.

    I used it for two reasons.  One it is was handy and on my desk.  Two it eliminates the variables you mentioned such as the USB to RS232 conversion and PC software elements.  I trust it to be accurate at much higher speeds. It more closely isolates the MCU to determine first if the problem lies there or elsewhere.  Since I don't have ready access to the exact system from the customer I chose to focus first on my area of expertise and responsibility.

    Having demonstrated that the MCU is capable of success, hopefully, Pak can now use this "known good" software on his or her platform in an effort to determine if the system is flawed somewhere else.

    Given that the system "worked" on a competitor's board, I suspect some subtle system level difference in the interfaces between the PC and the Stellaris/Tiva.

    Pak,

    Does the competitor board do the 3.3v to RS232 logic voltage level translation?  Our boards do not.  It is possible that at slow speeds some USB converters may "work" with a 3.3V logic input but at higher speeds require the proper RS232 voltage levels.

    Is ground connected between the boards/systems.  Again possible that things "work" with improper ground reference at slow speed but not at higher speeds.

    Dexter

  • Sorry for the delay answering but it has been an intense week of work with some other stuff going on. First of all, I would like to thank you for the time and useful help shown in this post.

    Back to the issue, I am testing again the UART devices and I have some promising and good news, if I setup for example UART3 without tying up to UARTStdio, and instead of that I connect it to the PC via an external FTDI TTL to USB converter, I can get more than 3Mbps (maximum of the FTDI device).

    So it seems, as  stated,  that the bottleneck here is the second ICDI-debug LX4F MCU, which translates from TTL level to USB level. 

    I haven't had enough time to test if I receive complete a long message now or if there is some interruption stopping the whole transfer.

    Is there any simple way to check if when I start to send a message, some other interruption or task masks the transfer? Something like the RTOS analyzer with DSPs.

    I am using CCS 5.3.00090 


    Regards.

  • Glad to learn that your transfer rate has improved.

    While I may have been correct about, "multiple suspects - not just the MCU" - directing blame to the 2nd LX4F was, "off mark."  That 2nd MCU manages the ICDI function - (via its USB to JTAG activity) and thus is not any part of your MCU-UART to PC transfer process.  Other than this ICDI role - I doubt there is any further interconnect between the 2 MCUs - on your board.

    That said - any/all other non MCU devices - in that signal pathway - do not escape suspicion...  (to include SW resident upon your PC)

  • Actually Pak is correct. The debug MCU does have a UART connection to the target.  We enumerate our debugger as three items on the PC.  DFU for updating the ICDI firmware, Debug for JTAG, and Virtual Serial port to provide a simple serial connection to the target MCU.

    I was previously unclear that Pak was using the ICDI as the UART translator.  I was under the impression that the UART to PC mechanism was identical to other previous tests he had conducted on other boards.  It appears in one case he was using our ICDI for USB to UART and in another case he was using something else.

    It is quite possible that our ICDI does not transfer at high baud rates.  It is not optimized for this.  As CB1 states, its primary purpose is JTAG.  The serial function is extra for light debug and status reporting from the target MCU.  We only test and run our examples at 115200.

    Near the reset button are two holes in the LaunchPad labeled TXD and RXD.  These are the digital signals for the UART connection between the target and the ICDI.  You should be able to tap those signals and use any other UART (digital 0-3.3V logic level) to USB converter and get potentially higher speeds.  I would examine the physical signals with a oscilliscope to determine if the lines are becoming too loaded for that speed.  If the logic starts to look too rounded use GPIOPadConfigSet to change the current drive setting for PA0 and PA1 (particularly the TXD pin).  The default 2mA drive can cause issues for very high speeds.  Particularly when you will not have more than one device on the pins.

    Dexter

  • cb1_mobile said:

    Glad to learn that your transfer rate has improved.

    Thanks a lot!!

    cb1_mobile said:

    While I may have been correct about, "multiple suspects - not just the MCU" - directing blame to the 2nd LX4F was, "off mark."  That 2nd MCU manages the ICDI function - (via its USB to JTAG activity) and thus is not any part of your MCU-UART to PC transfer process.  Other than this ICDI role - I doubt there is any further interconnect between the 2 MCUs - on your board.

    That said - any/all other non MCU devices - in that signal pathway - do not escape suspicion...  (to include SW resident upon your PC)

    Actually, it is part of my MCU-UART to PC transfer process, since this second MCU creates the Virtualcom to work against when the Stellaris Launchpad board is connected to the PC. Then the two MCUs are connected via UART0 for this virtual COM purposes.

  • cb1_mobile said:
    launchpad - which has 2 LX4F MCUs.  (one serves as ICDI)  And - it is possible (perhaps likely) that this 2nd MCU may be limiting the transfer speed.

    I recall that the (now dispatched) LM3S811-EVK employed an FTDI device - which enabled ICDI and a UART to USB pathway - so that both could be used in unison. 

    Dexter: "I was previously unclear that Pak was using the ICDI as the UART translator."   And that would make two of us...

    Review of that FTDI device's performance spec may indicate just how effectively the LX4F approaches.  (and as Dexter states - that added channel clearly is an "extra" - and to my mind deserves applause...)

  • PAk SY said:

    I haven't had enough time to test if I receive complete a long message now or if there is some interruption stopping the whole transfer.

    Is there any simple way to check if when I start to send a message, some other interruption or task masks the transfer? Something like the RTOS analyzer with DSPs.

    I have completed the task and I received the long message from every other UART not attached to uartstdio. However at these fast rates I get some frames not totally synched and I don't know if it is because of Stellaris behaviour or my PC receiving.

    System Analyzer is not working for me in the LM4F Stellaris Launchpad, is there any guide to set it up or any other way to check what is happening with all processes?

    Thank you.

  • I am not very familiar with the System Analyzer utility.  If this is the utility in CCS i believe it only works with the TI-RTOS (aka SYS/BIOS).  

    If you are already using the TI-RTOS then this should work and i'd suggest please ask the question on the BIOS forum.  If you are not already using the TI-RTOS it probably introduces more variables and uncertainty than is warranted and could make the problem harder to debug.

    In the latter case you are probably left with GPIO pin toggling to detect system events on an oscilloscope.

    Also keep in mind that merely having the JTAG debugger attached can in many cases impact real time performance.  Many IDE's are polling variables and system information in the background even while "free" running without breakpoints set. This polling can steal cycles from the main core.

    Another option might be that the device on Stellaris LaunchPad does have ETM trace capability.  You would need an advanced JTAG/ ETM debug module and probably either Keil or IAR.  Not sure which other vendors currently support ETM.  I don't believe Code Composer does at this time.

    Dexter