P&E Semihosting Console unexpected behaviour

[walter_gallegos]

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.

[walter_gallegos]

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.

[walter_gallegos]

Erich,

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.

Regards,

Walter

[BlackNight]

Hi Walter,

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.

Erich

[BlackNight]

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.

Erich

[walter_gallegos]

Hi Erich,

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 ?

Regards,

Walter

[BlackNight]

Hi Walter,

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

  printf("hello world!\r\n");

  fprintf(stdout, "Stdout output: %d\r\n", i);

  fprintf(stderr, "StdErr output: %d\r\n", i);

gives

hello world!

Stdout output: 0

StdErr 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:

hello world!

Stdout output: 0

S

t

d

E

r

r

o

u

t

p

u

t

:

0

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,

Erich

[walter_gallegos]

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 ?

Best regards.

Walter.

[walter_gallegos]

Hi Alice,

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 ?

Saludos/Regards

[walter_gallegos]

stdout and stderr have different behaviour.

Apparently stderr is treated as a character device.

Best regards,

Walter

[Alice_Yang]

Hello Walter,

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

Alice

[walter_gallegos]

Complementing my last post

Apparently the problem is at stderr stream.

saludos

Walter

[walter_gallegos]

Hello Alice,

The problem is "assert"; "printf" work as expected.

Best regards

Walter.

[walter_gallegos]

removing newlib-nano (collateral effect ~ +10K code) the console printout is

[Alice_Yang]

Hello Walter,

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 .

BR

Alice

[walter_gallegos]

Hi Alice,

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.

Regards/Saludos

Walter

[Alice_Yang]

Hello Walter,

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 ?

BR

Alice