where TRACE_CONFIG_READ is the trace level constant, and ret, id and myObjectSize are variables to be displayed.
In previous versions of Oasis (2.02, 2.10) this TRACE statement output the values I was expecting.
In the current version of Oasis (2.20), and M2M Studio, I get the following output in the Traces View of the Target Management perspective:
config_read returns %d, Id = %d, read %u bytes
The Oasis 2.20 doco indicates that TRACE() is a macro that eventually calls adl_trcPrint() - which takes a Trace Level and a sprintf() style format string.
My questions:
Has anybody else seen this issue when using Oasis 2.20 & M2M Studio?
Is it an issue with M2M Studio or Oasis 2.20?
Is there a workaround (other than manually constructing the string using wm_sprintf())
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.
Ta. I’ll try it and see how I go. This has to be better than doing the wm_sprintf() workaround - until I really need to see the value as an unsigned integer…
Also sort of indicates that the bug is in M2M Studio.
it didn’s use to work fine if you needed to print strings
this is also why i never encountered this problem in the betatesting stage.
so i agree with you on the bug part.
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.
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…)