• Locked Locked
  • Replies 16 replies
  • Subscribers 54 subscribers
  • Views 1561 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.

GUI Composer: UART stream from F28069 seeems to start overflowing sometimes

Ferdinand M.
Prodigy 80 points

I am using Windows 7 Professional Service Pack 1 and Code Composer Studio Version: 6.1.0.00104.

In GUI Composer I did a GUI witch is receiving a data stream over UART (Debug Probe: Texas Instruments Inc.XDS100 Ver 2.0) from the F28069M LaunchPad. The GUI shows an analog gauge witch is turning when you turn an incremental encoder connected to the LaunchPad.

Everything is working quite good, but sometimes when you start the application either in CCS GUI Composer or in standalone (GUI Composer Runtime) it seems that the incoming stream starts to overflow. A delay occurs between turning the encoder and this is displayed on the screen. This delay increases with the time the application is running.

I have tried it also with different PCs with the same behavior.

Thank you in advance!

Regards,

Ferdinand

  • Guru 192875 points
    Hi Ferdi,

    Can you try bursting out data a bit slower ie with some more delay? There seems to be a possibility that GUI is not able to handle big amount of data in a short time span.

    Regards,
    Gautam
  • TI__Genius 16220 points

    Hi Ferdinand,

    The gauge uses animation to draw the needle, it is not suitable to handle large volume of data. It is better to use a graph in your case, which it is optimized to drop incoming data if it is not able to keep up with the input stream of data.

    You can also try to increase the internal refresh delay to a larger number to prevent too many update to the gauge. Take a look at this wiki page.
    processors.wiki.ti.com/.../Debugger_Refresh_Rate

    Regards,
    Patrick

  • in reply to Patrick Chuong
    Prodigy 80 points
    Hi Patrick,Thank you for your ideas and tips!
    I played also with the refresh rate, which had no impact on the data coming over UART.
    Unfortunately I have to use the gauge to show the encoders turning in a demonstrative way, but I switched off the needle animation in the source code of the library and now the needle should display the data directly (It is now also able to jump).
    The perplexing matter for me is that the problem occurs only sometimes. I can start the application in standalone and it works fine for more than ten minutes. Then I stop and restart it again and after a few seconds the delay between the incoming data and the movement on the screen becomes more and more.
    The F28069 sends 10 characters every 100 ms at 115200 baud rate but I have tried also a period of 200 ms with the same result.
    Regards,Ferdinand
  • in reply to Gautam Iyer
    Prodigy 80 points
    Hi Gautam,
    This is also a quite good idea but I have tried it also witch update period of 200 ms instead of 100 ms and it seems that this behavior does not change. This is a bit hard to test, because the problem occurs only sometimes.
    As additional information: The F28069 should send 10 characters every 100 ms at 115200 baud rate.
    Regards,Ferdinand
  • in reply to Ferdinand M.
    TI__Genius 16220 points

    Could it be the values that come from the UART is outside the range of the gauge?

  • in reply to Patrick Chuong
    Prodigy 80 points
    Hello Patrick,
    Thank you for your answer! The values are limited by the F28069 to the range of the gauge.
    I have tried now to display the data also in a text area in GUI Composer and even at a transmission period of 200 ms you could see, that sometimes a delay occurs (or it sticks). If I do the same in a terminal (e.g. TeraTerm) it works always fine and the data are displayed quite periodic.
    Regards,Ferdinand
  • in reply to Ferdinand M.
    TI__Genius 16220 points

    This sound like the issue is not within the widget, perhaps there is an issue with the GUIComposer UART implementation. I'll ask the person who implemented the UART support to give you a hand.

    Regards,
    Patrick

  • in reply to Ferdinand M.
    TI__Expert 4150 points
    Hi Ferdinand,

    Did this always happen when you run the app for awhile, stop and then rerun it?
    Did this ever happen from a fresh start, ie, run your app right after the device is plugged in?

    The UART Monitor implements a very simple protocol with no synchronizing capabilities. Things might go out of sync depends on the state when you lauch off.

    Victor
  • in reply to Victor Yang
    Prodigy 80 points

    Hello Victor,

    Unfortunately it also happens when I do a fresh start. On my colleagues PC it first worked every time fine for several restarts and reconnections (so we thought already it is a matter of my PC and its slower CPU) but then we did another reconnection of the target to his PC and from that time he also had the described problem.

    It seems to be better with a longer pause between the data (e. g. 200ms instead of 100ms) but unfortunately not always.

    Best regards,

    Ferdinand

  • in reply to Ferdinand M.
    TI__Expert 4150 points

    Ferdinand,

    1.Did you use the ftdi serial through usb or hooked up to the pins directly?

    2.On your "restarts" did you terminate and restart the application process?

    This should help us to narrow down if it is a driver issue.

    Victor

  • in reply to Victor Yang
    Prodigy 80 points

    Hello Victor,

    1. I use the virtual Com-Port via USB on Channel B.
    2. In standalone (GUI Composer Runtime) I pressed the button “Initialize Target” or exited the application without any difference in behavior afterwards. In CCS I most of the time terminated the application by pressing the red quadrat and started it afterwards by starting a new debug session.

    I hope this information helps you.

    Regards,

    Ferdinand

  • in reply to Ferdinand M.
    TI__Expert 4150 points
    We don't have many options here. Next thing we could do is probably hook up a COM port monitor to monitor if any packets are lost. Also, try to use a lower baud rate, like 9600.

    I am convinced that it must be caused by some mismatch in synchronization between the host software and the target side code that occurred when you restarts the setup. If you observe this after you unplug the device, restart the GUI composer/CCS(close the application and relaunch it) and then plug in the device, let me know.

    is it possible for you to provide us with the necessary projects/binaries to reproduce the issue?
  • in reply to Victor Yang
    Prodigy 80 points

    Hello Victor,

    I could send you the application and binaries for GUI Composer Runtime, but without an encoder it will not work. How can I send you the files?

    Regards,

    Ferdinand

  • in reply to Ferdinand M.
    TI__Expert 4150 points
    You can send them to me at v-yang@ti.com
    As a last resort, please test out this:
    "I am convinced that it must be caused by some mismatch in synchronization between the host software and the target side code that occurred when you restarts the setup. If you observe this after you unplug the device, restart the GUI composer/CCS(close the application and relaunch it) and then plug in the device, let me know. "

    Thanks,
    Victor
  • in reply to Victor Yang
    Prodigy 80 points

    Hi Victor,

    Sorry for my late answer, but I were out of office for the last days.

    I tried out what you wrote, but I have not mentioned any difference in the behavior afterwards.

    Am I using a too high refresh interval? I thought that at 115200 baud 10 characters every 100ms should work?

    Regards,

    Ferdinand

  • in reply to Ferdinand M.
    TI__Expert 4150 points

    It could be, that's why I suggested you to try it at a lower baud rate.

    Insert some delays in your code where it handles internal update of the data you want to send as well.

    For example, if I am doing a temperature sensor, maybe take the reading every 0.5 sec and use a 9600 baud rate should suffice.

    The idea is, the device may not be powerful enough to handle large stream of data if you are taking readings at 0.001sec and generating a lot of buffer for the rs-232 chip to handle. The host side basically have access to unlimited buffer handled by the system OS, so the overrun is most likely target side related, or a bug in the rs-232 driver which is highly unlikely.

    So in summary my suggestion is

    1. reduce internal refresh/update rate

    2. reduce baud rate, try some lower numbers from below

    • 9600
    • 14400
    • 19200
    • 28800
    • 38400
    • 57600