• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 5382 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.

TM4C123GH6PM: random characters with 9600 baud rate after power on cycle

supreeth anil
Prodigy 230 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: UNIFLASH, , MAX232

Hello All,

I was trying to implement a circular buffer using UART. In the testing stage I simply output an ASCII character('a') inside infinite while loop. It was working fine till I disconnected the power supply and turned it ON again(about 30 secs delay). At this point of time some random character started appearing on the screen instead of ASCII 'a'. We need to press reset switch every time after each power ON cycle to print the characters properly.  Instead of using Direct Register Access program model I tested with some Tivaware examples. It didn't solve the problem. An interesting thing to be noted here is that it happens only with 9600 baudrate. When I changed the baudrate from 9600 to 115200, the code started printing characters as expected (It only created problem at the very first power on cycle which is acceptable). From PC side I am configuring it for 9600 8-N-1. I tried PuTTy, teraterm, hyperterminal and arduino serial monitor with no success (teratern even refused to print those characters). When I repeated the experiment with Arduino IDE and Arduino UNO, it worked perfectly fine with all softwares. This behavior is so random in nature ie if I don't give more than a couple of seconds delay between power ON and OFF the problem doesn't come. I have discussed a similar problem in the following thread but at that point of time putting a delay between UART init and infinite while loop solved the problem.

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/534352

Some screen shots are attached for your reference. 

Any help would be greatly appreciated

  • 0
    Guru 13040 points
    Supreeth,

    This seems to be related to whatever you are using to convert TTL uart to RS232 level. How do you connect your TM4C to the PC? Maybe the power up sequence is such that the device converting is not able to detect the speed?

    You mention success with Arduino setups, but is the adapter the same? Still, your Arduino is likely to operate on an "easier to read" 5V environment...

    Regarding your code, I can only suggest that after configuring your peripherals (either GPIO's, UART's, anything), always wait for it to be available. For example:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_UART0)));

    On a separate note: a few dirty characters before UART comm shouldn't be much of a problem, anyway... The communication protocol must be able to discard invalid commands.

    Bruno
  • 0 in reply to Bruno Saraiva
    Prodigy 230 points
    Hello Bruno,

    I am using TM4C123GXL (Tiva C Launchpad) for writing firmware. By default, the UART0 is connected to the on-board Stellaris ICDI which comes as a virtual serial port on PC.

    Thanks for the code suggestion and I have already inserted peripheral ready check after initializing UART0 as mentioned but that did not solve the problem.

    A few dirty characters before UART comm is actually not a problem. But once the device is powered ON, every time one need to press reset switch for displaying the actual characters on the screen. The reason behind the successful execution on 115200 baud rate is still a mystery for me.
  • 0 in reply to supreeth anil
    Guru 13040 points
    Hello!
    Interesting... do you have a logic analyzer available? You could see the actual UART transmitted signals by probing that TX0 empty hole on the Launchpad. If you don't, you can divert that signal out to an external RS232 converter to see the bytes.
    I suspect that the TM4C is actually sending the proper bytes, and that the problem lies on the ICDI MCU... The above would confirm that.
    If so, maybe the "ICDI MCU" needs more time to settle after a power reset? You could be sending the bytes too soon, and for some reason it detects a wrong transmission speed??? Just guessing here...
    There is also firmware on that chip, in case you don't know - and maybe your Launchpad does not have the latest fw... I'm not sure how to view that, but usually the more recent flash programming software, such as UniFlash, is supposed to update the ICDI firmware if needed.
    Regards
    Bruno
  • 0
    Guru 27665 points
    It is quite possible for a UART to detect a character start at mid character. If the characters are formed in a particular way and sent close enough together then it can continuously mis-sync.

    See if inserting a small delay makes a difference. Upping the stop bits may help as well.

    Robert
  • 0 in reply to Bruno Saraiva
    Prodigy 230 points
    Hello Bruno,
    I will get access to a logic analyzer in one or two days. I will update the forum with the results. Meanwhile I am trying to update the firmware but I am not able to download UniFlash or LM Flash programmer from TI website (It is showing a 504 error). Is there any other alternate links?
  • 0 in reply to supreeth anil
    Guru 13040 points
    Supreeth,
    The link here seems to be working: processors.wiki.ti.com/.../Category:CCS_UniFlash
  • 0 in reply to Bruno Saraiva
    Prodigy 230 points
    Hello Bruno,

    The link is working. I think there is some problem with my browser/PC. I did the following things as suggested by you and finally succeeded

    1) Updated the firmware - No Success
    2) Changed the stop bits to 2 - No success
    3) Diverted the signal out to an external RS232 converter - Success

    I think there are some timing/power up issues with ICDI hardware. Anyways I will test it further.

    Thanks Bruno and Robert for your help.
  • 0 in reply to supreeth anil
    Guru 92251 points

    supreeth anil said:
    I think there are some timing/power up issues with ICDI hardware. Anyways I will test it further.

    I think the problem might be that the neither the ICDI UART receiver or TM4C123GH6PM transmitter have a pull-up on the UART signals. At power-up the TM4C123GH6PM UART transmit signal may float to an indeterminate level causing the ICDI receiver to see the start bit of a character.

    The external RS232 converter might have a pull-up on the receive signal which avoids the problem.

  • 0 in reply to supreeth anil
    Guru 117855 points

    The latest theory proposed (pull-up UART_TX) - while logical - appears NOT to have factored in the following (facts in evidence):

    supreeth anil said:
    once the device is powered ON, every time one need to press reset switch for displaying the actual characters on the screen.

    Now if we are able to assume that those, "actual characters" are not "illegal characters" - the pull-up's absence has, "caused no issue."

    And:

    supreeth anil said:
    The reason behind the successful execution on 115200 baud rate is still a mystery for me.

    Once again - if  "successful execution" implies, "w/out illegal characters" - absence of pull-up R is, "Off the hook."    (dismissed as suspect)

    As investigators we must,  "follow & respond to ALL  "facts in evidence"- even when inconvenient!" 

    As a general ruling/guidline - such use of proper pull-up R upon UART_TX IS recommended...     Yet - based upon the evidence on hand - the "absence of pull-up R @ UART_TX" - appears to escape,  "Judgement as Guilty" - at this time - and in this place!"

  • 0 in reply to cb1_mobile
    Guru 10570 points
    Agreed, I also doubt the pullup is the issue. I think most likely is that the ICDI is getting confused about the start of character and syncing to a point part way through the byte. In which case increasing the stop bits or adding a short pause every n bytes will change the behaviour. The short pause would allow a proper resynchronization. A break character would probably do the same.

    At the higher baud rate you might have good fortune with your mismatch or the transmit from the micro might have a small delay. It wouldn't take much to change the behaviour completely.

    Robert
  • 0 in reply to Robert Adsett72
    Prodigy 230 points
    Even I tried to put a PUR on TXD pin on the board. But it did not solve the problem. Earlier I tried increasing the stop bit count to 2 but I did not succeed. Adding a short pause every n bytes solves the problem but I just wanted to find the extreme test results. "If an arduino UNO hardware with same setup could easily transmit data without any delays why not Tiva C" - This was the inspiration behind my experimentation
  • 0 in reply to supreeth anil
    Guru 13040 points

    supreeth anil said:
    If an arduino UNO hardware with same setup could easily transmit data without any delays why not Tiva

    Do understand that the problem is not in the Tiva! It is in the middle device which converts the UART messages to an USB virtual serial port!

    DID you probe the UART lines on the pad as I suggested earlier?

    My theory is still that if you wait a bit further until you start to transmit messages, the issue will disappear. You are powering up both the Tiva AND the converter at the same time, and start sending bytes before the converter is ready to do its job.

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Bruno Saraiva said:
    Do understand that the problem is not in the Tiva!

    Are you "absolutely sure" of that?      Willing to, "Bet the farm?"

    We know  "nothing" of poster's handling of this particular board - nor the condition of his MCU - don't you agree?

    I submit that "more info is required" - prior to "removing the MCU" from the "list of suspects."

    Consider this - might that "middle device" (which you claim to be "Guilty") have "succeeded" w/ poster's Arduino?     What then?

    Absolute claims/assertions (most always) require "Absolute Data" - which has yet to arrive...

  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    Are you "absolutely sure" of that?      Willing to, "Bet the farm?"

    This is very easy betting, for it's poster's farm we're talking about, not mine. I am giving my opinion, he is free to take it.

    cb1_mobile said:
    might that "middle device" (which you claim to be "Guilty") have "succeeded" w/ poster's Arduino?

    Absolutely not possible: when he uses Arduino, he certainly does not use the TI's Launchpad ICDI Serial to USB converter, but rather something else - possibly a MAX232 module, or maybe something which is already part of that Arduino board.

    Still, this is why I've asked (twice) that poster probes the UART transmission which is coming out of the target TM4C with a logic analyzer, DIRECTLY on the exposed pad of the launchpad, so that he sees what is REALLY coming out of the Tiva. Again, my line of reasoning: the ICDI is nothing more than a Tiva chip, which does other things besides receiving UART bytes and converting them to a "virtual USB port" to the PC, and it is to be expected that his short program in the target TM4C starts spitting bytes out much before the ICDI is ready. When the UART Rx of the ICDI finally wakes up, bytes are already flowing, and the receiver can detect a transmission half way through a byte.

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    My friend - are there not "MANY" other facts in evidence?

    While our JTAG/SWD "Pod of choice" is J-Link (or beyond) we have "hundreds of times" used "ICDI" and NEVER has poster's issue been noted! And we have used his same 9600 Baud rate - (this rate was long a standard for our past boards - when distance trumped speed.)

    If the ICDI "stands Guilty" - which is your "absolute claim" - would not such occurrence have "visited" the multitudes - here? And a forum search reveals this NOT to be prevalent - possibly (even) beyond ANY mention!

    Absolute claims prove hard to sustain - breaking that habit may prove fruitful...
  • 0 in reply to cb1_mobile
    Prodigy 230 points
    Hello All,

    Sorry for the late reply. I didn't use any logic analyzer because a 3.3V FTDI cable from sparkfun, when connected between the exposed TxD pad and the PC, solved the issue.
  • 0 in reply to supreeth anil
    Guru 13040 points

    Thanks for the feedback, Supreeth.

    Let the record show that a "FTDI cable" is a TTL UART to USB converter:

    Whatever the problem was, it WAS in the ICDI chip. I still believe it was running out of sync during startup, despite fellow's belief that thousands having used the launchpad ICDI for UART would have raised the flag before.

    No proof yet, but the flaky "evidences" suggest such.

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Clearly you've - along w/many others - noted the "R9-R10 debacle" - visited upon all "123 LPad" users - which yields, "ON-GOING" and perhaps in excess of 500 postings here!

    Yet - to my best knowledge - "never" has such a, "Failed @ one specific baud rate" post appeared here - nor in the "Three other ARM Forums" in which I am active.

    Is it not "possible" - perhaps even "likely" - that the "timing between PC & MCU board" and/or the "USB Cable" (NOT used when the FTDI cable is used) also proves suspect?    Further - poster just reported, "a 3.3V FTDI cable from Sparkfun, when connected between the exposed TxD pad and the PC, solved the issue."       Should not that cable have connected to RxD pad - as well?      

    There are "none" of the "normal/customary" tech "proofs" - which would better support your claim of, "absolute Guilt" of the ICDI.      (has not emotion - despite the clear absence of compelling, interlocked facts - locked-in your claim?)

    To place blame - fully, completely and ONLY upon this vendor's ICDI - with the (admittedly) scant evidence - is premature at best - and (still) AVOIDS the measurement requests - which "You yourself were caring & clever enough to request!")