TRACE() macro calls not working


Not sure if this should be in this forum, or the OpenAT forum…

I’m using M2M Studio in conjuction with OpenAT Oasis V2.20. I’ve moved over an existing project that has a lot of TRACE() macros in it, of the form:

TRACE (( TRACE_CONFIG_READ, "config_read returns %d, Id = %d, read %u bytes", ret, id, myObjectSize ));

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:

  1. Has anybody else seen this issue when using Oasis 2.20 & M2M Studio?
  2. Is it an issue with M2M Studio or Oasis 2.20?
  3. Is there a workaround (other than manually constructing the string using wm_sprintf())

ciao, Dave

Hi Dave,

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 :wink:
This explains why “%s” is not working in traces…

I found the Javadoc explaining the authorized format characters:
Indeed, the “%u” is not recognized :confused:

So definitely, it seems that we can only display numeric values in traces, and only using authorized characters by Java formatting…

I guess that if you change your TRACE statement to:

TRACE (( TRACE_CONFIG_READ, "config_read returns %d, Id = %d, read %d bytes", ret, id, myObjectSize ));

you should get the correct display…

Actually, %s has never worked in any version of Open-AT since 3.03 (probably earlier, I don’t know).

This has always been a documented limitation.

… and a right pain in the sitting-area! :angry:

i’m using wm_sprintf to format the strings i wind to output before i feed them into the TRACE macro.
never had any problem since.

yes, but… it’s taking two lines :smiley:

Exactly! :angry:
And an extra string buffer!

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… :question:

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…
:arrow_right: 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…)

Hi All.

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.

ciao, Dave

The DEBUG, FULL_DEBUG, and RELEASE symbols are available to you to do your own conditional-compilation checks to prevent this… 8)

you can even write your own macro to accommodate the extra lines of code 8)


You’re right - but it’s a bit of a kludge to fix somthing that used to work fine…

I still think this is a bug in M2M Studio.

ciao, Dave

it didn’s use to work fine if you needed to print strings :wink:
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.

ciao, Dave

It looks like %p has the same effect. :angry:

This is basic stuff - it really should have been sorted by now! :angry: :angry:

It is possible to have both TMT and the M2MStudio Trace view displaying the same traces simultaneously - see: viewtopic.php?f=78&t=3476&p=13658#p13658

If you do this and have TRACEs containing %u and/or %p you will see that they are correctly displayed in TMT, and incorrectly in M2MStudio.

This goes to prove 2 things:

  1. The expansion of these tokens is being done by the PC tools - not in the Target;
  2. The bug is in M2MStudio - not in the TRACEs coming from the Target.