Someone know if following behaviour is a bug or a tool setup error; and a workaround or fix ?
The expected printout was "assertion....", in one line.
Tools : KDS 3.2.0, GCC, P&E Multilink Universal.
removing newlib-nano (collateral effect ~ +10K code) the console printout is
Could you please describe it clearly ?
Which board, and what about the project you download,
you'd better tell me the steps how to reproduce the phenomenon .
I'm working on a custom board with MK12DN512VLK5. The project is a co-operative multitasking ~50K firmware, C over ProcessorExpert, no RTOS, compiled with GCC. Sorry, is an outsourcing project under NDA.
To check tasks operation I add some pre and post-conditions using asserts ( assert.h ) and redirect stderr at linker
P&E debug Startup :
Our technique checking pre/post-condition using assert work as expected; we can trap all assert fails; only console printout is apparently wrong.
I test on simple printf project on KDS v3.2, it can work well.
And my configuration is the same with yours .
I see your project have printf some words, and what should it be , what about the right result ?
The problem is "assert"; "printf" work as expected.
Complementing my last post
Apparently the problem is at stderr stream.
stdout and stderr have different behaviour.
Apparently stderr is treated as a character device.
I think in KDS, the bareboad project can not directly use the file operate , for
to enable the file support, an OS and a filesystem is needed first.
The detail you can refer to this thread :
fopen() and fprintf() with Semihosting on Kinetis K10
Hope it helps
Look at screen captures, fprintf() function work as expected using stdout stream but not using stderr stream.
I think the problem could be related to the unbuffered default behaviour of stderr stream. Throw stderr stream, in some part of the process, was added a new line and a carriage return after each character.
I'm really surprised that no one else trap this issue. Nobody uses assert() to validate pre- and post-conditions ?
For reference, assert() work as expected by default in TI CCS 6x with GCC
assert() is a powerful tool to build robust firmware;
NXP support, comments ?
I have made some tests, and to me this indeed might be related to the stdio implementation in the ARM/Launchpad libraries.
I get a different result if not using the newlib nano (using the stdlib):
fprintf(stdout, "Stdout output: %d\r\n", i);
fprintf(stderr, "StdErr output: %d\r\n", i);
Stdout output: 0
I'm puzzled by that newline for StdErr, but at least it looks better.
While with newlib nano I get same as you report:
I have not checked with newer ARM versions of the GNU libraries, but maybe using newlib gets you closer to what you need?
I hope this helps,
Thanks for help,
Unfortunately, switching to last stable version of ARM GCC libs I lost the semihosting service. The debugger hangs-up for long time and finally show an error message.
with GNU Tools for ARM Embedded Processors 5 - Q1 2016
After the internal error KDS and pegdbserver still running even after close KDS
Is necessary manually kill this process before run KDS again.
Back to default KDS 3.2.0 libs, the debugger back to work again. Maybe incompatibilities between versions ?
yes, changing to a new GDB (especially from a 4.x to a 5.x) could cause issues. I have not used that version in my production environment yet, but I'll give it a quick try.
Ok, I have the same problem as you see:
I'm going to report this to P&E.
I tried it as well with the Segger interface, and here it works. So it must be something in the P&E GDB server.
Thank for confirm, I don't have a Segger pod but, as comment before, assert() work well with others environments. I agree, P&E GDB server is a good suspect in this case.
Only to confirm this as P&E issue,
We receive last week some J-LINK pods, so I experiment this morning.
Segger GDB work as expected; same target hardware and same firmware as in others tests.
Retrieving data ...