printf to debug window?

cancel
Showing results for 
Search instead for 
Did you mean: 

printf to debug window?

2,838 Views
Contributor III
Can anyone advise or point me to a document that specifies how to set up printf to redirect to the a debugger window?  I have seen this in demos, but I can't find anything in the CW 7.1 folders, sample projects or documents on it.

Basically, it seemed like printf was being set over the P&E BDM to the debugger.

Any help would be fantastic.


Message Edited by Adam on 2009-02-02 08:23 PM
Labels (1)
0 Kudos
7 Replies

11 Views
Senior Contributor II
What board are you using?  Many of the boards are different.
 
If you are using a M52221DEMO, for example, all you have to do to the default project is add console_io_cf.c to it and make sure CONSOLE_IO_SUPPORT is defined to 1.
 
This is done by default for you in the "CONSOLE_INTERNAL_RAM" target, but not for the others.
 
The biggest issue with this is it is very slow -- like 5 characters per second -- you can add simple line buffering to the console printf (getting you to 5 lines per second) by adding this to your file:
 
#include <stdarg.h>
#define assert(x)  if (! (x)) asm { halt }
 
static
void TERMIO_PutChar2(char ch)
{
    static char buffer[128];
    static int i;
  
    buffer[i++] = ch;
    assert(i <= sizeof(buffer));
    if (ch == '\n') {
        __write_console(1, buffer, &i, 0L);
        i = 0;
    }
}
 
 
int
printf(const char *format, ...)
{
    int n;
    va_list ap;
   
    set_printf(TERMIO_PutChar2); /* set up TERMIO_PutChar2 for writing */
   
    va_start(ap, format);
    n = vprintf(format, ap);
    va_end(ap);
   
    return n;
}
 
 
 
0 Kudos

11 Views
Contributor II

Is there anything like this for the CW10.4 ewl libraries?

0 Kudos

11 Views
Contributor III
That's one thing I am unclear on.  Where does this output go?  Is it to a UART?  Or to come special interface over P&E?  Is there any way to speed it up?
0 Kudos

11 Views
Senior Contributor II
Deep in the bowls of printf, the routine TRKAccessFile() is called.  TRKAccessFile() sets up some registers indicating the data to be printed and then invokes trap #14. The trap #14 handler then executes a halt instruction, freezing the CPU until the Debugger intervenes.  When the debugger detects that the trap has been taken, it then examines memory pointed to by the registers, and copies those characters to a debugger console window.  The debugger then continues program execution past the halt.  No uart is involved.  Basically, you get one "file access" in the amount of time it takes to break into the debugger, examine registers, examine memory, and continue -- about 200ms.  The real issue is that the new "tiny I/O" console functionality sends printf'd characters *one character at a time* to the debugger console, to save RAM, so the performance is very slow.  The simple mod I gave you speeds this up to be "one line at a time", rather than "one character at a time", at the expense of a 128 byte buffer.
 
Does that answer your question?
 
0 Kudos

11 Views
Contributor III
The reason I asked is because I tried this and tried the other method (console_io.c),

I run the code, step in, see it going to your printf, and calling the termio_putchar2, like indicated above and still I run, see it hit the printf statements, and I see no debugger output anywhere.  I feel like I am missing something.
0 Kudos

11 Views
Senior Contributor II
There may be a few more steps...  Just to confirm it all, please check:
 
1. make sure in your "Link Order" project tab for the target you are building that console_io_cf.c is listed.  Just because it is in the "Files" tab (which is for all targets) does not mean it is in the "Link Order" tab for your particular target.
 
2. make sure in the target settings for your particular target, under Language Settings -> C/C++ Preprocessor, that you see "#define CONSOLE_IO_SUPPORT 1".
 
3. then go to Debugger -> CF Exceptions and make sure "46 Trap #14 for Console I/O" is checked in two places.
 
4. make sure that your trap #14 handler executes a halt instruction, followed by an rte.  You can confirm this by single stepping into the trap #14 that is in TRKAccessFile().  If you are using the default exceptions.c, this is taken care of by these lines:
 
#if CONSOLE_IO_SUPPORT  
   TrapHandler_printf,              /*  46 (0x0B8) TRAP #14                   */
#else
   asm_exception_handler,           /*  46 (0x0B8) TRAP #14                   */
#endif  
But you should confirm this with the single-step since the VBR gets potentially copied, modified, etc., and the halt/rte is required for the debugger console printf to work.
 
What processor are you using?
 
What I'm telling you works for the 522xx family, at least.
 
-- Rich
 
 
 
 
0 Kudos

11 Views
Contributor III
Hi,
Thanks for the help.  Your tweak _IS_ much better.  5 lines per second is great.  What I was missing is that I was assigning it to interrupt 14 not 46.  Bad oversight on my part.

And I am doing this on the 5232 and 52277 and seems to work great.
0 Kudos