TRACE_MSG(lm, fmt, args)

Added by run ye almost 7 years ago


I am using the ZBOSS stack and compiled for CC2530 in IAR.
But I can only see some disorganized information through the serial debugging assistant.
For example:
蕲&?144 651 nwk_cr_mesh_routing.c:740 蕲?
蕲?145 651 zb_scheduler.c:105 蕲?ba05d5040000
蕲&?146 651 nwk_cr_mesh_routing.c:747 蕲?
蕲?147 651 z7 651 zb_scheduler.c:252 蕲?cc05d5044501d0030000
蕲&?148 651 nwk_cr_mesh_routing.c:776 蕲?

I want to see the effect of the function TRACE_MSG(lm, fmt, args), Can any body tell me how to learn the ZBOSS stack?
Thanks in Advance.

Replies (5)

RE: TRACE_MSG(lm, fmt, args) - Added by Alexander Voronov almost 7 years ago

Which debugging assistant do you use? Have you tried WinComDump that is under stack/devtools/win_com_dump?

RE: TRACE_MSG(lm, fmt, args) - Added by run ye almost 7 years ago

I use the serial debugging assistant of AccessPort.exe. Now I want to learn how to add my own App, can you guide me to start my application?

RE: TRACE_MSG(lm, fmt, args) - Added by Alexander Voronov almost 7 years ago

Yes, of course. Glad to help you.
To start with, you can examine the code in ZBOSS tests. I can recommend you to build zdo_startup test first of all.
All you need is just to add the test into your IAR project (choose only one role a time - coordinator, router or end device). To build end device role check that ZB_ED_ROLE is defined in preprocessor definitions of your project.
Also you can use network simulator (stack/devtools/network_simulator) to start developing your apps without hardware. Please, check script in stack/tests/zdo_startup to get familiar with how to use it.

RE: TRACE_MSG(lm, fmt, args) - Added by run ye almost 7 years ago

First of all, Thank you very much!
I know you said above, and I have implemented these features. Now, I want to achieve transparent transmission of two nodes. For example, the coordinator send a message to a router, the router return a message to the coordinator and display the message on the computer through the serial debugging assistant. Thank you for your help!

RE: TRACE_MSG(lm, fmt, args) - Added by DSR Support almost 7 years ago

First of all, please, notice that debug serial trace messages are sent in binary packets and they contain two types of data:
1. Traffic data from the radio
2. Debug messages from the application trace (i.e. TRACE_MSG macro)
That's why you see this strange terminal output. If you save the captured data from your terminal to binary(not text) file and open it in a hex editor, you will see the repetition of the patterns 0xDE 0xAD 0xYY 0xYY 0xYY 0xYY ... . The first two bytes are signature, the next one is a type of data (0x), length, and payload. Payload for different types of packets is different too. For detailed information of how does this protocol works, please see source files.
The current implementation of ZBOSS doesn't support general terminal output, like printf() functions or some simular. So you are unable to see the debug information in real-time. To make this feature you have to implement your own trace system or change existing one in the HW device, or write PC application, which can parse incoming data on the fly from the serial port.
Also you can use WinComDump utility, which is distributed with ZBOSS stack. It is located in stack/devtools/win_com_dump and you can investigate its sorces. As I previously mentioned, the data flow from the device includes two types of data and you can run win_com_dump.exe file to see the trace in the readable form in the following way:

win_com_dump.exe \\.\COMx trace.log traffic.dump

where COMx is yor serial port
trace.log - output file for TRACE_MSG() calls
traffic.dump - binary traffic dump, which can be converted to .pcap file by using dump_converter
The runnig sequence is following:
1. Start win_com_dump
2. Start your HW
3. While HW is running, you CAN see the output messages by opening trace.log file. There is a little hack here: If you are using file manager, like FAR, you can select the file, open it by pressing F3 and see .log file in real-time.
4. Stop your HW.
5. Analyse .log and .dump(or .pcap) files.