Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

how to print to debugger console in IAR?

Other Parts Discussed in Thread: CC2540

Hello,

i am using IAR to program a CC1110 and would like to be able to printf() to the debugger console. how can i do this? i have tried the Log Breakpoint and that's neat, but i want to be able to print more specific output to the console.

i came across the __message macro in the C-Spy documentation, but i am not sure how to use it.

 

thanks on advance,

-r

  • Hi rl,

    all you have to do is to #include <stdio.h>  and use printf() in your code. For this to work with the debugger console you will have to go to Project options -> Linker -> Output (tab) and in the "Format" section where you have selected "Debug information for C-SPY" you need to have "With I/O emulation modules" checked (this requires "with runtime control modules"). This will make the linker use its special low-level I/O routines (putchar() , getchar() ) which will route it to/from the debug terminal I/O console.

    When entering debug mode you get the debug console window displayed by selecting View -> Terminal I/O from the top menu. You will probably notice that if you try to printf too much text it will make the output lag a bit. But it can surely be a handy tool for debugging your application anyway.

    (For the curious, you can see in the disassembler that the putchar() / getchar() functions linked into the code when using I/O emulation are just NOP instruction dummy functions. The C-SPY debugger will set a hardware breakpoint in this function, and whenever this breakpoint is reached it will read out the register to read/write the character. The communication overhead causes a small delay for each character. A side-effect of using I/O emulation is that the debugger will reserve one hardware breakpoint for each of these two functions (if you are using them), so you will get fewer hardware breakpoints available to use in your other application debugging.)

    You can find some more information about "I/O emulation modules" in the IAR user manual: Help -> 8051 Embedded Workbench User Guide.

  • Hey Esy,

    I've followed your steps above to enable printf statements while developing with IAR using my CC2540 bluetooth low energy board.

    For some reason, when I use printf, i get the outputs to appear, but I begin to lose functionality from my chip.  For example, I am connected my board to an iPhone4s.  Under normal circumstances, I can scan for devices, connect to them, and read back all their available services.

    When using printf statements, I can scan for available devices, but when I issue a connect command, I do not receive services.  I do however see output messages caused by the printf.

    Any ideas?  Thanks

    Jonathan

  • Hi Jonathan,

    I know I'm late at answering you, so you might have found a solution to your problem.

    I think the reason for your above mentioned problem is that the emulated I/O (via printf()) is interfering with the CPUs handling of the RF protocol (here: bluetooth low energy). As I described above, the emulation requires the use of hardware breakpoints, so in reality when you print out your strings, the debugger will halt the CPU for a short period (it happens in the background so you don't really see it), repeatedly for each character.

    Since this is not happening super-fast, the halting and delays is most likely to block the CPU from being able to service its radio interrupts and other RF protocol handling in order to maintain an RF link/connection with the other bluetooth low energy devices.

    When using the radio in a link with another device you often have quite strict real-time requirements, so I don't think using the emulated I/O is compatible with running an RF protocol. I think you will have to use other means for your debugging, without the use of hardware breakpoints that halts the CPU for longer periods (typically, if you do use manual hardware breakpoints, you will have to restart your application or at least RF connection, when you want to resume).

    Perhaps you'll have to go back to debugging with setting variables, or toggling LEDs or I/O pins, which can be done much quicker.

  • thanks esy, I appreciate your response.

    I've setup UART on my device now, so I'll be using that to print debug commands to.  

  • Thanks for this info ..  my module is now triggering output.  In my case I tried to printf("ok"); and it keeps printing ooooooooooooooooooooooooooooo forever...  any ideas how I can fix this?  it would be so useful for debugging!!

  • You can try using "buffered terminal output".

    -Jonas

  • a question can I point the printf to the uart or I need

    to implement my own printf which send output to uart?

    thanks

  • Hi Friend,

                    I tried all settings to print the line using printf statement but i can't get the output in Terminal IO.

    Can u please suggest any idea.

  • Hello,

    How one can see the outcome of Printf() in order for me to debug my C code on IAR for the cc2540 ?
    I use the instructions in this link (statusbits.wordpress.com/.../) but it doesn't work for me, because I need instructions for cc2540!!!
    Please help me. if you know!

    Thank you very much in advance,
  • Do you do "go to Project options -> Linker -> Output (tab) and in the "Format" section where you have selected "Debug information for C-SPY" you need to have "With I/O emulation modules" checked (this requires "with runtime control modules")?