• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1423 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.

UART Debugging [Concerto]

Philipp L.
Intellectual 795 points

Hello everyone,

How can I print Debug-like messages with my Concerto without having the Debugger plugged in?
When the Debugger is plugged in and the device runs from RAM, I get the System_printf-Messages in the CCS-console. 

But when I run the device from flash (no debugger connected, just Power ON), how can I print messages on the console/terminal?
Can I use the "System_printf()"-Function oder Logger-functions somehow? 

Or do I have to set the registers for UART-configuration (BAUD-rate, ... etc) and do it by myself?

Thank you for your answers,
Philipp 

/edit: What I just saw: Program execution seems to be much much slower when the debugger is connected - for example: I configured a timer to toggle a LED every 1second. With the debugger connected, nothing happened for a long time. Without the debugger, it works - every second a toggle.

  • 0
    TI__Guru* 96960 points

    Hi Philipp,

    Which version of XDCtools are you using?

    When you write to the CCS console (via the CIO buffer), the breakpoint is hit. CCS reads the data and then restarts the target. This can have major impact on the real-time performance. Are you using SysMin or SysStd? You can look at this link for more details: http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_System.

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 795 points

    Hey Todd,

    thanks already for your support!

    My xdctools version is 3_22_04_46, and bios version is 6_32_05_54. And I am using Code Composer 5.1.1.00031.

    And yes, you are right, the System_printf-calls slow the system down. If I comment them, it's fast again.

    But the main question remains: How do I get System_printf or another function to print messages on the debug console? When I start up with the debugger in CCS, there is some UART-initialization running in the background. How can I do this from flash without the debugger and CCS, just print out over the USB-UART at some Baudrate? So that I can read it with a standard serial console program?

    Or is this impossible with System_printf or an equivalent function, do I have to write my own little "driver"?

    I read the Using_xdc.runtime_System document, but it didn't really bring me forward. Is there an example?

    Big thanks for your help!

    -Philipp

  • 0 in reply to Philipp L.
    Intellectual 795 points

    I think I might have solved my problem: 
    I found a way to supply the SysMin-Module with a custom output function, and for that function I took the UART-functions from the uart_echo M3-Example (with initializations before)

    I used this in my *.cfg file: "SysMin.outputFxn = "&UARTSend";"

    Is this the "right" way to do it? Or is there a more intelligent way? It is working, though..

    /edit: It really seems to work, but what I dont like is: I can only write out strings with a maximum length of ~17 characters, everything after that is cut away. This seems to come from the Define OUTMAX in runtime/System.c, which has that value.
    I thought there was a Buffer in SysMin, whose size I can configure with "SysMin.bufSize = 0x ..." in my cfg-file, .. but this does not seem to have any effect.. It seems like SysMin's buffer is not used at all, it looks more like just System_printf's OUTMAX is used as buffer and no more. How can I change this to SysMin's buffer? Or is this not possible when I use a custom outputFxn in my SysMin?

  • 0 in reply to Philipp L.
    TI__Guru* 96960 points

    Philipp,

    Using SysMin's outputFxn is definitely one approach (and probably the easiest). The supplied function is not called within a System_printf. Instead the characters are buffered in SysMin's internal buffer. When a flush occurs the output function is called with the buffer and the length of the buffer. Note this function may be called multiple times since it honors ordering. Since SysMin overwrites when it is full, the current write location might be in the middle of the buffer. In this case, the output function is called with the second portion of the buffer (and length) and then with the start of the buffer (and length). This allows the user to get the characters in order.

    Note: there might be '\n' intermixed in the buffer that is given to the output function.

    I did this quick test and it appears to work fine. Create the SYS/BIOS generic Task Mutex example. Add the following line into the .cfg file:

    SysMin.outputFxn = "&myOutputFxn";

    Then add the following into the mutex.c file.

    Void myOutputFxn(Char *string, UInt length)
    {
        printf("%d\n", length);
    }

    Put a breakpoint in the myOutputFxn and run the program. You should hit the break point. The length should be 259. If you look at the buffer in the memory window, you should see the output.

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 795 points

    Todd,

    I tried the example you suggested, and it worked exactly like you described. So I thought the error might be located in my Output-Function, and that was it. I used the non-blocking UART-Send-Function, and that function always stopped when the FIFO was full. I changed to the blocking function, and it works fine now. I don't care about blocking or non blocking, because I call the flush() in my idle-task..

    So, thank you for your help!

    Philipp