P&E Semihosting Console unexpected behaviour

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

P&E Semihosting Console unexpected behaviour

3,806件の閲覧回数
walter_gallegos
Contributor I

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.

 

153427_153427.pngpastedImage_0.png

ラベル(1)
0 件の賞賛
返信
16 返答(返信)

3,177件の閲覧回数
walter_gallegos
Contributor I

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.

pastedImage_0.png

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

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

0 件の賞賛
返信

3,177件の閲覧回数
BlackNight
NXP Employee
NXP Employee

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

0 件の賞賛
返信

3,177件の閲覧回数
BlackNight
NXP Employee
NXP Employee

Ok, I have the same problem as you see:

pastedImage_0.png

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

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

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

pastedImage_0.png

After the internal error KDS and pegdbserver still running even after close KDS

pastedImage_2.png

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

0 件の賞賛
返信

3,177件の閲覧回数
BlackNight
NXP Employee
NXP Employee

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

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

For reference, assert() work as expected by default in TI CCS 6x with GCC

pastedImage_0.png

assert() is a powerful tool to build robust firmware;

NXP support, comments ?

Best regards.

Walter.

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

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

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

stdout and stderr have different behaviour.

pastedImage_0.png

Apparently stderr is treated as a character device.

Best regards,

Walter

0 件の賞賛
返信

3,177件の閲覧回数
Alice_Yang
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

Complementing my last post

pastedImage_0.png

Apparently the problem is at stderr stream.

saludos

Walter

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

Hello Alice,

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

pastedImage_1.png

Best regards

Walter.

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

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

pastedImage_0.png

0 件の賞賛
返信

3,177件の閲覧回数
Alice_Yang
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信

3,177件の閲覧回数
walter_gallegos
Contributor I

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

pastedImage_0.png

P&E debug Startup :

pastedImage_2.png

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

0 件の賞賛
返信

3,177件の閲覧回数
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Walter,

I test on simple printf project on KDS v3.2, it can work well.

pastedImage_0.png

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

0 件の賞賛
返信