[C64XP_0] printed after every character sent to debug console output in CCSv5

In v5.x all the output goes to a single console by default so CCS inserts the CPU-core name in front so that you can tell which core it is coming from.  For your example is each character being sent by a separate printf?

For me this is what I see, however here I am just using a single printf on each core

[TMS320C66x_0] hello world

[TMS320C66x_1] hello world

For single core debug sessions it does not insert the core name.

I can't see an option to disable this in 5.1, I will ask around.

John

I'm using a single core so there is no need to print which one the output is from. I tried to uncheck the box in my config but the output didn't change.

This is my ccxml config:

It works ok for me in 5.0.1 as well

When it is set to use different consoles my console looks like this (note how the line at the top indicates that it is showing output for a specific CPU:

When it is set to use the same console for all CPUs then it looks like this (note+how the cpu info is no longer on the top but is now beside the printf output.

Try terminating your debug session and launching again to make sure the setting gets applied.  Note that in 5.1 if it is a single core device you won't have to do this.

John

Works like charm after restart!

Still I don't see why I need to disable the option. It is a single core device but maybe I have some faulty configuration? (see printscreen in earlier post)

Thank you!

John,

Hurray for Google!  It directed me here.

This also solved my problem.  I would never have thought to right click on the .ccxml file either.  The default CCS behavior was making assert() statements much more difficult to read.  Instead of  "Assertion failed ..." you'd get "[C64+_0]A [C64+_0]s [C64+_0]s [C64+_0]e [C64+_0]r [C64+_0]t [C64+_0]i [C64+_0]o [C64+_0]n [C64+_0] [C64+_0]f [C64+_0]a [C64+_0]i [C64+_0]l [C64+_0]e [C64+_0]d ...".  As you can imagine, that makes it a little difficult to see *which* assertion failed. (To work around it, I'd cut/paste into Notepad, and search/replace all the [C64+_0] tags out.  It works, but it gets old quick.  I guess that's incentive to make fewer bugs and throw fewer assertions, eh? ;-) )

Is it possible to improve CCS's default behavior here for the shared console case?  The current CCS behavior adds that tag in the shared CIO console whenever a given CPU flushes its CIO buffer.  (For stderr, that's after every character.)  Should it instead only output that tag in the shared CIO console when switching between CPUs?  That way if the same CPU is outputting a bunch of stuff, you get the [C64+_x] tag only once, and then if another CPU outputs a CIO message, you get one tag for that, etc...

--Joe

Joe,

That is not a bad idea.  So you would see something like this

[C64+_0]

Assert

Assert

Assert

Fix these already!

[CortexA_0]

Hello

[C64+0]

Assert

Assert

....

I will file a CQ request for it and we can discuss with the debugger team to see if it is possible.

Regards,

John

John,

Yeah, something like that would be great.  I suppose it could still get confusing if multiple CPUs were sending a ton of updates, but that's what the "separate console" mode is for.  :-)

For the more common case of printing out only exceptional information, or one CPU being "chatty" and the others only printing out crashes or the like, that sort of filter on the ID tags would be ideal.

Thanks!

--Joe

I filed SDSCM00042133 to track this.