• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 25 subscribers
  • Views 1104 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.

EK-LM4F120XL: Serial Port Communication / C# Visual Studio Software Developing problems.

Tales Duque
Prodigy 140 points
Part Number: EK-LM4F120XL
Other Parts Discussed in Thread: EK-TM4C123GXL

Hello fellow programmers, recently I developed a program on Code Composer that can acquire electrical signals and give me the informations about the signal, such as frequency, RMS, etc. After that I wanted to create a software on Visual Studio so I could see it visually, both the values and the graph. For that I have to use Serial Port Communication, but sometimes when I try to run my program, apparently something gets lost in the way and the error below occurs. I have the baud rates paired up, and I have designed a program that works most of the time. Could anyone help me with this problem? Im going to insert some printscreens so you guys can see the code/error.  (Baud Rate 9600)

Thanks, Tales Duque.

(What the UART is sending)

  • 0
    TI__Guru** 119915 points
    Hello Tales,

    Do you suspect the issue on the TM4C side, or the PC side? If on the TM4C side, I'd advice sniffing the UART lines with a logic state analyzer to see if any packets are lost or report errors. You also could use an oscilloscope as well to verify signal integrity, baud rate etc.

    If it's on the PC side, I'm afraid we won't be able to help much, as our expertise lies with the device and it's operation, not so much Visual Studio and OS drivers.

    Also the LM4F devices have been obsoleted, so you should really consider using TM4C projects and hardware moving forward. The EK-TM4C123GXL would be comparable to your listed hardware.
  • 0
    Guru 117850 points

    Tales Duque said:
    apparently something gets lost in the way and the error below occurs.

    While "colorful" - the "exactness of such error" (presented via (only) 3 lines of your serial monitor) - also (apparently) - "gets lost along the way!

    Might you better describe the error?     Especially beyond,  "RMRMS1: 1.628;RMS2: 1.626\r\n"       (that's the only error presentation - I note.)

    Those chars in highlight - to my mind - should (not) appear.    

    • The lead "RM" may have resulted from an inadequate, "Screen-field clear."
    • the "\r\n" suggest that their "Screen-Control function" was not recognized.    (i.e. CR and LF)
  • 0 in reply to cb1_mobile
    Prodigy 140 points

    Well, I need to "identify" the string that is coming in and then compare to a pattern so that then I can split it and remove parts that are not needed. Although, sometimes it seems like the UART communication fails and one message scrambles up with another line, I dont know if it has to do with the hardware or with the program... The thing is, when I go to CCS, the terminal in there sometimes show the same error, wich I think it means that it has nothing to do with my code on Visual Studio...

    I would like to know if there is a way that I could remove that RM (I dont think \r\n interferes on the comparation with the pattern set) or any other strange thing that comes in through the serial that is not comparable to the pattern...

    Thanks!

  • 0 in reply to Tales Duque
    TI__Guru** 119915 points
    Hello Tales,

    I would recommend looking at the UART lines with a scope and see if you can observe the RM being transmitted over UART. If so, that would be the source of the issue. Also looking at your code, I'm guessing everything that happens measurement wise is via interrupts? Do you know if any of those interrupts could trigger and disrupt the UART process possibly? Also I wonder if making sure the UART FIFO is flushed after a printf command would help. You could try adding that in after the printf call.

    Anyways, until we get a verification of the UART data being output incorrectly, it's hard to consider this an issue with our TI device.
  • 0 in reply to Tales Duque
    Guru 117850 points

    If indeed - the CCS terminal reveals that "same" (unwanted, lead) "RM" then I agree w/you - such is unlikely to result from a flawed (external device) clear.

    Is the unwanted, lead (always) "RM?"      Your answer provides an important clue - as that "RM" IS indeed present w/in your UART's FIFO - and its (unwanted, lead) presence - likely signals an "incorrect FIFO unpacking."

    The fact that your (external device/terminal) displays "\r \n" - suggests to me that those "Control Codes" are not being processed by your external device.      (We'd expect to see an "automatic" carriage return - followed by a line feed...)