got the same issue: it was working with TMT tool, but not with M2M Studio. BTW, other traces (including arguments) are displayed correclty in M2M Studio…
I pushed a little further, and found that all was coming from the “%u” statement!
Indeed, in my M2M Studio error log (.log file in my .metadata workspace directory), I get an exception: java.lang.IllegalArgumentException: Malformed conversion specification=%u byte
Seems that M2M Studio uses Java to format string traces coming from the target
This explains why “%s” is not working in traces…
I also suspect that it makes the trace (a lot) less efficient:
It seems to me that TRACE does not actually send the formatted string to TMT; rather, it sends the formatting specification and the arguments - and it’s the TMT that actually builds the complete string for display.
You can see this if you get all the traces going in TMT, then disconnect TMT and connect Hyperterminal instead…
(or if you have some serial data monitoring facility).
So, I guess this process just can’t cope with arbitrary, variable-length string arguments - hence %s is not allowed…
Well, that’s how it seemed to work before M2M Studio - dunno if that’s changed anything…
I guess it’s the same thing with M2M Studio, since it’s backward-compatible with all Wireless CPU Firmware versions. And I don’t think the firmware is wondering itself if it’s speaking to TMT or M2M Studio: it justs outputs the raw format string…
that’s make me thinking it’s a deeper issue than a tools-related one: the TRACE api should fully support the sprintf syntax… Or should be configurable to do so (in order to avoid breaking performances by calling systematically sprintf on the target…)
Thanks all for testing this. Glad that it’s not just me!
Also, the API doco states that TRACE() and DUMP() macros are conditionally compiled when the DEBUG or FULL_DEBUG macros are defined. Using a local string buffer and wm_sprintf() to format the output is wasteful of code and stack space when compiled in RELEASE mode.
This used to work in 2.10 & 2.02 - but doesn’t now. I guess this should be reported as a BUG - but should it be reported to the M2M Studio or OpenAT/TMT (or both) devs?
At least using a separate string buffer and wm_sprintf() call gives us a workaround.
I guess that if you change your TRACE statement to:
it didn’s use to work fine if you needed to print strings
Ahh - I mis-spoke. I meant about using %u, not %s. It’s very clear in the API doco that you can’t use %s in TRACE(), so I too was using wm_sprintf() in the few occasions I was outputting strings to the TRACE() macro.