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.
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,
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to 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
In reply to Jonathan Cohn:
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!!
In reply to Rob Platek:
You can try using "buffered terminal output".
In reply to Firefighter:
a question can I point the printf to the uart or I need
to implement my own printf which send output to uart?
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.
In reply to Emocs:
If my post answers your question, please click on "This Resolved my issue" button to benefit others who have the same issue.
How to detect button hold in CC26x2, CC13x0, CC13x2 SDK.
660 Zigbee devices in the same Zigbee network!
How to setup Mosquitto on Raspberry Pi and make Contiki/Contiki-NG cc26xx-web-demo do mqtt publish to it.
How to connect Contiki-NG cc26xx-web-demo to IBM Watson IoT Platform
How to build and run Contiki-NG cc26xx-web-demo running on LAUNCHXL-CC1310 and rpl-border-router on Raspberry Pi with slip radio running on LAUNCHXL-CC131
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.