[ECOS] diag serial port and debug serial port conflict?

[ECOS] diag serial port and debug serial port conflict?

[Charles F.]

Hi. I am working on a ddb-4373 board and it seems have this problem: The default settings of the diagnostic serial port and the gdb serial port are both set to use serial port 0 (which is the port A on the 4373 board). 
It's obvious that the GDB stub has initialized the port 0 and used it to load my ecos program onto the board. My ecos program, however, stops to interact with GDB after it tries to initialize its diagnostic serial port (also 
serial port 0). The code is in hal_diag.c function hal_duart_init(). If I delete the line which writes to the port registers or choose to use port 1 as the diagnostic port in the conficuratoin tools, the problem doesn't exist. 
(But anyway, I still can't get correct diagnositc output).
It seems like that we can't initialize the same port twice when we are still using it after our first time intialization. Can anybody help me on this problem? Thank you!

Charles

Re: [ECOS] diag serial port and debug serial port conflict?

[Jonathan Larmour]

"Charles F." wrote:
> 
> Hi. I am working on a ddb-4373 board and it seems have this problem: The default settings of the diagnostic serial port and the gdb serial port are both set to use serial port 0 (which is the port A on the 4373 board).
> It's obvious that the GDB stub has initialized the port 0 and used it to load my ecos program onto the board. My ecos program, however, stops to interact with GDB after it tries to initialize its diagnostic serial port (also
> serial port 0). The code is in hal_diag.c function hal_duart_init(). If I delete the line which writes to the port registers or choose to use port 1 as the diagnostic port in the conficuratoin tools, the problem doesn't exist.
> (But anyway, I still can't get correct diagnositc output).
> It seems like that we can't initialize the same port twice when we are still using it after our first time intialization. Can anybody help me on this problem? Thank you!

Are you absolutely sure they are being initialized to the same speed? I
wouldn't have thought a serial port would just drop dead if initialized
twice with the same parameters!

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] diag serial port and debug serial port conflict?

[Charles F.]

I am sure they are initialized to the same speed. Yesterday I tried to use
non-optimization setting (delete the -O2 switch in general build settings)
to compile ecos and it works! I guess there is something wrong with the
optimized serial port intialization code. I have experience porting WinCE to
4373 board and once I met this kind of problem too. Am I right?

Charles

----- Original Message -----
From: "Jonathan Larmour" <jlarmour@redhat.co.uk>
To: <charles@zh.t2-design.com>
Cc: <ecos-discuss@sourceware.cygnus.com>
Sent: Thursday, July 27, 2000 10:23 PM
Subject: Re: [ECOS] diag serial port and debug serial port conflict?


> "Charles F." wrote:
> >
> > Hi. I am working on a ddb-4373 board and it seems have this problem: The
default settings of the diagnostic serial port and the gdb serial port are
both set to use serial port 0 (which is the port A on the 4373 board).
> > It's obvious that the GDB stub has initialized the port 0 and used it to
load my ecos program onto the board. My ecos program, however, stops to
interact with GDB after it tries to initialize its diagnostic serial port
(also
> > serial port 0). The code is in hal_diag.c function hal_duart_init(). If
I delete the line which writes to the port registers or choose to use port 1
as the diagnostic port in the conficuratoin tools, the problem doesn't
exist.
> > (But anyway, I still can't get correct diagnositc output).
> > It seems like that we can't initialize the same port twice when we are
still using it after our first time intialization. Can anybody help me on
this problem? Thank you!
>
> Are you absolutely sure they are being initialized to the same speed? I
> wouldn't have thought a serial port would just drop dead if initialized
> twice with the same parameters!
>
> Jifl
> --
> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223)
728762
> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own
fault

Re: [ECOS] diag serial port and debug serial port conflict?

[Jonathan Larmour]

"Charles F." wrote:
> 
> I am sure they are initialized to the same speed. Yesterday I tried to use
> non-optimization setting (delete the -O2 switch in general build settings)
> to compile ecos and it works! I guess there is something wrong with the
> optimized serial port intialization code. I have experience porting WinCE to
> 4373 board and once I met this kind of problem too. Am I right?

Quite possible. It would be useful if you could investigate this further
and determine whether it is a bug in our code (non-standard code that the
compiler is "allowed" to misoptimize), or a bug in the compiler itself. And
report it either to us, or the gcc folks at http://gcc.gnu.org/ with an
appropriate small test case :-).

Thanks,

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] diag serial port and debug serial port conflict?

[Nick Garnett]

"Charles F." <charles@202.96.178.16> writes:

> I am sure they are initialized to the same speed. Yesterday I tried to use
> non-optimization setting (delete the -O2 switch in general build settings)
> to compile ecos and it works! I guess there is something wrong with the
> optimized serial port intialization code. I have experience porting WinCE to
> 4373 board and once I met this kind of problem too. Am I right?


This raises one possibility:

The HAL_DUART_WRITE_CR() macro contains a delay loop that is used to
keep the Z8530 happy. It looks like with -O2 this loop maybe being
eliminated or optimized so it is too short. However, exactly the same
code appears in the initialization for the stubs, and GCC shouldn't
eliminate such loops. So it is not at all clear what the difference
here is. 

I have just compiled this code with -O2 and it seems to keep the delay
loop intact. Maybe your board has a faster CPU? The code is currently
set up for a 133MHz part. Try changing the value of ZDEL in
plf_z8530.h to something greater (and compiling with -O2) and see if
that makes a difference.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK