• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 744 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LM3S811 UART0 Use non-jtag use

Kristian Doggett
Intellectual 320 points
Other Parts Discussed in Thread: LM3S811, EK-LM3S811, CC3100

We have a LM3S811 on a custom development board and want to use UART0 (PA0/PA1) for communication.  Because UART0 is configured by default to print to console, are there any special considerations when using UART0 for a regular UART link?

  • 0
    Guru 20670 points

    For stellaris questions please post here http://e2e.ti.com/support/microcontrollers/stellaris_arm/default.aspx

    I don't believe there is any problem. The UART works exactly the same, the difference is that UART0 is usually connect to a serial-usb converter (in the launchpad it's the ICDI)

  • 0
    Guru 85655 points

    Kristian Doggett said:
    We have a LM3S811 on a custom development board

    Stellaris MCU's are NRND. Also LM3S811 is one of the Stellaris Device that is EOL due to Flash Corruption Issue.

    Because of the above mentioned issue, it is recommended to shift development to Tiva ARM MCU's

    - kel

  • 0
    Guru 117850 points

    Kristian Doggett said:
    Because UART0 is configured by default to print to console

    That, "Configured by default" proves true only upon the EK-LM3S811 - where an external USB->UART converter IC resides on the pcb - there is no such "default configuration" in-built to the stand-alone MCU.  Your statement, "custom development board" suggests yours is "not" an EK-LM3S811 - yet provides no (needed) detail as to your custom board connections or deployment.

    Usually Port "A" imposes default peripheral functions upon the bulk of its GPIO.  I2C, SPI & UART - Port "A" pins - all (likely) default away from GPIO into, "Serial Peripheral du jour." 

    Special considerations - if the UART is to talk to an RS232 or RS422/285 external device - external line drivers must be added.  Feeding RS-232 signal levels into any MCU directly (usually) will damge the MCU. 

    One here has claimed, "Flash Corruption" - yet that is "confined" to past Stellaris "Tempest" class MCUs!  Your LM3S811 is (famed) "Sandstorm Class" - thus escapes that misfortune...  Our tech firm has almost 500 such LM3S811 MCUs in the field (some > 6 years now) - no such "Flash Corruption" has occurred - nor is likely to arrive...

    Same poster asserts "EOL" and that is equally incorrect - again being confined to "Tempest" class MCUs.  (guru class usually "fact checks" bit better...)

  • 0 in reply to cb1_mobile
    Intellectual 320 points

    Thank you so much for your response.  I'll tell you a little more about our setup to put my answer and your response in context.  We are running the PortA (PA0 Rx) UART0 directly to the PortD (PD7 Tx) UART2.

    PortA (PA0 Rx) UART0

    LM3S811 solder to custom PCB board.

    PortD (PD7 Tx) UART2

    Tiva C Series Launchpad connected to headers solder to board.  The Launchpad has a CC3100 Wifi booster pack attached.

    When I scope the PD7 Tx line, it is sending the correct data at the correct baud rate, but nothing comes in on the LM3S811 PA0 Rx UART0.

    I am not asking another question to you, it could be a half dozen causes, but I wanted to rule out and PortA nuances on the LM3S811.  It sounds like my configuration will not be affected by any default PortA configuration.  Thanks for ruling this out for me!

  • 0 in reply to Kristian Doggett
    Guru 117850 points

    Thank you - yet now it appears a TM4C MCU (launchpad) has joined the mix - and your not quite clear enough if (PD7-Tx) resides w/in LM3S811 or the TM4C.  Do note that vendor's TM4C design team "blessed" PD7 w/unwanted NMI default status - you must "jump thru hoops" to properly use that pin.  (appears you did this as you claim, "sending correctly.")

    You state that PD7-Tx (from either LM3S811 or TM4C) "sends correct data" yet "nothing comes in" on LM3S811 PA0-Rx.  Have you ohmed out this connection?  Have you scoped PA0 at the LM3S811 while sending - do proper signal levels arrive - at PA0?

    As stated - our LM3S811 design is 5+ years past - that MCU's manual (under GPIO section) should detail any special treatment of Port A pins. From memory now - I believe that the ICDI chip was wired into PA0 on the LM3S811 eval board.  Worth your fact-check, that.  Such surely establishes that PA0 may perform well as UART-RX.

    "Nothing comes in" is too vague - if signal levels arrive (at the actual PA0 MCU pin) - NOT on a board header (you suspect) is wired into PA0 - then if PA0 is indeed a default UART - and properly enabled - such data should be recognizable by various UART Register observations.

    And again - the horrors of flash corruption (despite the incorrect claim of another) have not landed on your MCU...

  • 0 in reply to cb1_mobile
    Intellectual 320 points

    Problem solved.  I wired the TX to TX lines and RX to RX lines.

  • 0 in reply to Kristian Doggett
    Guru 47900 points

    Kristian Doggett said:
     I wired the TX to TX lines and RX to RX lines.

    You've just "joined" the ranks of skilled Launchpad - 0-ohm MCU-MCU - connected brigade. 

    Your RX to RX connections don't concern - but TX to TX may have damaged one or both sides.  I'd monitor the output levels of each TX over a several hours time period - checking for port damage.  As our last post (surmised) you really hadn't routed PD7 (from either S811 or 4C123) into S811's RX pin.