Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • Locked Locked
  • Replies 10 replies
  • Subscribers 55 subscribers
  • Views 1671 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.

Slow CIO - output sent to stderr is printed 1 char per second

Deomid Ryabkov
Intellectual 435 points
Other Parts Discussed in Thread: CC3200

This is weird. It seems that output sent to stderr is printed at a rate of 1 char per second, while output sent to stdout is fine.

I took the "blinky" example and added the following code to main.c:

    GPIO_IF_LedOff(MCU_ALL_LED_IND);
    
    setvbuf(stdout, NULL, _IOLBF, 0);
    setvbuf(stderr, NULL, _IOLBF, 0);
    printf("Hello, world!\n");
    fprintf(stderr, "Error\n");
    fprintf(stdout, "Done\n");

    //
    // Start the LEDBlinkyRoutine
    //

i'm setting both stdout to line buffered mode, the print strings to stdout, then stderr, then stdout again (using fprintf this time, but it doesn't matter).

The result is: "Hello world appears instantly", then i get E-r-r-o-r-\n printed one char at a time, with approximately 1 second between each, then "Done" is printed instantly and the code continues on to blink the LEDs.

I'm using CCS 6.1.2.00015 on Ubuntu 15.10

Here, i even shot a video: https://youtu.be/R1Am9HSkQuw

  • TI__Guru* 85400 points
    Moving to CCS Forum

    Regards,
    Gigi Joseph.
  • TI__Guru**** 169224 points
    Hi,

    That is certainly interesting, but which board are you using?

    I tried to reproduce this here with my TM4C129 Launchpad on my Ubuntu 14.04/64 and CCSv6.1.2, but unfortunately I got a quite quick update rate with both stderr and stdout outputs.

    Therefore this may be tied to the device, JTAG debugger or the project itself. Can you share the project you are using and list which dependencies it has (SDKs or something else)?

    Regards,
    Rafael
  • in reply to desouza
    Intellectual 435 points

    hi Rafael

    i'm using CC3200 launchpad (i initially posted it in the CC3200 forum, that's why i didn't mention that).
    I'm using SDK 1.1.0, in case it matters (but i don't see anything relevant in 1.2.0 changelog).

    attaching the archive of the project dir

    ...

    stupid forum insists on pasting it as a video or something and refuses. here's a link instead.

  • in reply to Deomid Ryabkov
    TI__Guru**** 169224 points
    Hi,

    Thank you for sending the test case; I was able to reproduce this issue and found out this only happens in very specific conditions.

    I tested the same Launchpad in Windows and it worked. I then tested other ICDI-based boards in Linux (LM3S9B90 and TM4C123 Launchpad) and found out that only the LM3S9B90 shows the problem, which also shares the same FTDI-based ICDI debug probe. The TM4C123 Launchpad is also an ICDI but it uses a more modern implementation.

    Due to the fact the ICDI debug probe technology as a whole is not being actively supported, unfortunately I am afraid this issue will not be fixed.

    I apologize for the inconvenience,
    Rafael
  • in reply to desouza
    Intellectual 435 points

    this sucks. how am i supposed to debug then, given that TI's libc insists on sending stout and stderr to CIO?

    where is the bug? is is possible for me to fix it myself?

  • in reply to Deomid Ryabkov
    Intellectual 435 points
    the bug is present on CC3200 launchpads sold today, how is this not supported? what should i use instead?
  • in reply to Deomid Ryabkov
    TI__Guru**** 169224 points
    Hi,

    I completely understand how frustrating it is. However, given this device/platform seems to be primarily supported in Windows (I can't find mentions of a Linux SDK or documentation), I will forward this thread to the device tools group and see if what are their plans to address Linux.

    I apologize for the inconvenience,
    Rafael
  • in reply to desouza
    Intellectual 435 points

    Linux support is actually quite good.

    I'm able to use CCS and CCS Cloud, this is the only issue i'm having, and it looks like it's pretty minor.

  • in reply to Deomid Ryabkov
    Intellectual 435 points

    i started working on MSP432 and see this behavior too. and not just on Linux, on Windows too.

    also, it turns out that stdout is also delayed, but after each line, not char.

    so... it's not only about some deprecated debug connection and obscure OS, it's real.

  • in reply to Deomid Ryabkov
    TI__Guru**** 161100 points
    stdout is buffered
    stderr is unbuffered

    This will make a big difference in CCS as CCS has to halt the target, read and then run it again. So for stdout this would be on a line of output. For stderr as it is unbuffered that will be for each character and will be very slow. They type of debug connection used and the hostOS will also greatly impact the speed as some debug connections are faster than others and the USB driver implementation varies by hostOS.

    One potential solution is to enable the output to be directed over Serial Wire Output (SWO) which is present on most Cortex M based devices. This is not something that we support in our toolset today but is being looked into as it has the potential to make things a lot smoother.

    There are some general speed improvements available in the latest emulation pack update. This should make things a bit better for MSP432 at least.

    Regards,
    John