• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 1141 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123 Launchpad Download Working Differently With CCS vs Standalone

Tim Simerly
Genius 9975 points
Other Parts Discussed in Thread: TM4C123GH6PM, EK-TM4C123GXL

Hey Tiva Support:

I have a weird thing happening on my TM4C123 Launchpad that I can't figure out.  I am using 2 UART ports: UART0 and UART2 and developing and debugging using CCS.  I have built my code base and have everything working with receive and transmit working as expected on UART0 and UART2 with no issues as long as I download using CCS and run it from CCS.  But as soon as I stop CCS and press the reset button and/or reapply power by pulling out the USB cable and plugging the board back into my PC, UART0 transmission/reception is working fine with no issues and UART2 receive is working fine with no issues, but I can't get UART2 to transmit out anything.  I look on the scope at the TX output of UART2 and see activity when I download my code using CCS and run.  But as soon as I stop CCS and reset the board or reapply power, I see no activity on the TX pin of UART2.  Can you explain what may be going wrong?  I have tried using LM FLASH Programmer and programming the board with the .bin file and have also tried building using the Release version with CCS and still I can't get anything to come out the TX pin of UART2.  However no isssues with the RX pin of UART2 - reception is working fine by either running via CCS or by reset of the board and reception/transmission of UART0 works fine with CCS or after a reset and no CCS.  Am I missing something here as to why only half of UART2 would be working when using CCS vs not using CCS?  Please advise.

Thanks,
Tim Simerly

  • 0
    Guru 86745 points

    Hi Tim,

         Does the same happens with working example programs, such as uart_echo?

         Does your CCS project have a startup file? Attach a copy of CCS project folder here. So, others can review it.

    - kel

  • 0
    Guru 92251 points

    Tim Simerly said:
    But as soon as I stop CCS and reset the board or reapply power, I see no activity on the TX pin of UART2.

    UART 2 Tx is on the same pin as GPIO PD7 on a TM4C123GH6PM. The TM4C123GH6PM datasheet notes that PD[7] needs to be "unlocked" before it can be changed from a GPIO function:

    Does the code "unlock" the PD[7] pin to allow it's use for UART2 Tx?

    If not, wondering if downloading the program in CCS somehow "unlocks" the PD[7] pin. [This is a guess - I haven't tested it]

  • 0 in reply to Chester Gillon
    Guru 117855 points

    Chester Gillon said:
    wondering if downloading the program in CCS somehow "unlocks" the PD[7] pin.

    That is one, "great postulate" - and especially devilish should it prove true!

    Poetic justice that vendor employee is "hoisted" (apparently) by vendor's "sparse, under-highlighted" manual description of, "NMI as default behavior!"  Hundreds here have "fallen victim" - vendor resists any/all suggestions to better alert the "unknowing!"  (and in this case - even when the victim is vendor, "kin!")

    Should note that paid IAR performs "no such" automatic NMI nor JTAG pin, "unlocking."

  • 0 in reply to cb1_mobile
    Guru 92251 points

    cb1_mobile said:
    That is one, "great postulate" - and especially devilish should it prove true!

    A test program was created which dumps the contents of the GPIO_PORTx_LOCK_R and GPIO_PORTx_CR_R register values to the UART0 port [the test program just displays the values of those registers - it contains no code to alter them]. The same results were reported on a EK-TM4C123GXL when running the program after download the program with CCSv6 and after pressing the reset button:

    GPIO_PORTA_LOCK_R=0x00000001 GPIO_PORTA_CR_R=0x000000FF
    GPIO_PORTB_LOCK_R=0x00000001 GPIO_PORTB_CR_R=0x000000FF
    GPIO_PORTC_LOCK_R=0x00000001 GPIO_PORTC_CR_R=0x000000F0
    GPIO_PORTD_LOCK_R=0x00000001 GPIO_PORTD_CR_R=0x0000007F
    GPIO_PORTE_LOCK_R=0x00000001 GPIO_PORTE_CR_R=0x000000FF
    GPIO_PORTF_LOCK_R=0x00000001 GPIO_PORTF_CR_R=0x000000FE

    The value of GPIO_PORTD_CR_R confirms that PD[7] is "locked" both after a CCS download and subsequent reset. Therefore, my "postulate" is proven false.

  • 0 in reply to Chester Gillon
    Guru 117855 points

    One would have hoped for such - proves that hallowed vendor is simply bit "inept" in detailing/alerting new users to the "NMI is default, (long known - yet allowed to persist/fester), gotcha."  

    Your considered test thus (apparently) removes, "devilish" (in this instance) from the, "log of vendor behaviors."   

    Haven't that specific MCU's manual handy now - but do note that other MCUs in that class also may employ PG5 as (potential) UART2_TX.  Switching to that PG4/PG5 pin pair - or migration to a different UART - escapes the possible intrusion of, "pin defaulting as NMI" as causal nexus.  

    Unsolved mystery remains - "How does the "release" from the IDE "break" that UART_TX connection?  

  • 0 in reply to cb1_mobile
    Guru 117855 points

    Perhaps while this (near dead) horse still has some breath - might it be that your test - absent poster's set-up/config code for UART2 - proves not to be a full nor proper test of the IDE's attachment upon NMI pin behavior?  

    I'm not at all critical of your test - nor your effort in devising - simply observing that the, "combination of set-up/config code for such NMI pin" - along then with the attachment of the IDE - may (however briefly) "free that set-up/config'ed pin from its NMI status!"  Or not.  (we really don't know...)

    Poster is duly advised to employ the standard, "unlock then repurpose code for PD7" (if indeed that is poster's chosen pin for UART2_TX) - or perhaps more simply - migrate to another UART pair - not afflicted by NMI's unwanted - yet glaringly under-emphasized {not by moi} encroachment.

    And one further issue - we're rarely told (i.e. "never") if RS232 level shifters or UART to USB converters have, "joined this UART to PC mix."  (we are told that a PC is the "other end" of this UART commo channel - suggesting use of a special PC (w/serial port - my firm's case) or aged PC (one still employing standard RS232 serial port) or the more likely USB port with some (undescribed) UART to USB converter interposed...  

    If the latter - the disruption of power to user's MCU board (as described by complaining {vendor!} poster) - may cause some disorder @ the (assumed) UART to USB converter and/or the remote PC - each able to "break/alter" the MCU's UART_TX connection...  (if a UART to USB converter receives its power from the PC (likely) - then that converter usually provides signal to the MCU - while the MCU is not under bias.  (i.e. when the power to the MCU is removed) We're told this is not harmful to the MCU - but "not harmful" does not have the same strength as, "unaffecting full/complete peripheral operation - upon power's restoral..."