Re: [ECOS] Using the TCP/IP stack from the anonymous CVS server

[Richard Wicks <rich at accetnetwork dot com>]

On Wednesday 19 September 2001 03:51 am, Jonathan Larmour wrote:
> Richard Wicks wrote:
> > On Tuesday 18 September 2001 02:33 pm, Jonathan Larmour wrote:
> > > Richard Wicks wrote:
> > > > GDB cannot be used when the TCP/IP is included?  Is this a bug across
> > > > all platforms or simply the XScale?  Working without debug capability
> > > > will slow down development, are there any known workarounds?
> > >
> > > That's not quite right. The restriction is that you cannot include
> > > stubs in your application when debugging over the network: that's
> > > because when you do that, the stubs will "claim" the debug channel,
> > > which will close your TCP connection.
> > > Jifl
> >
> > OK - disable the stubs on the application or redboot?  Can you tell me
> > how to do it with ecosconfig?
>
> The application. They should be default disabled anyway.

To confirm, this means setting the user_value of 
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS in my ecos.ecc file to 0, correct?  I 
still do not understand CDL flawlessly, although I am working on it.

Anyhow, if it should have been disabled then it must have been since I did 
not enable it.

In the meanwhile, I have traced the problem to the ethernet driver which I 
compiled into the application.  I will explain fully in detail below.

> > In either case, right now I'm not even using the ethernet to debug with,
> > only the serial channel.  Still, redboot IS compiled to support debugging
> > over the network although I'm not using it.  I've been having some
> > trouble recompiling redboot without ethernet support.  Here is what I'm
> > doing.
> >
> >  ecosconfig new iq80310 redboot
> >  ecosconfig import redboot_ROM.cfg (included at end of this mail)
> >  ecosconfig remove CYGPKG_DEVS_ETH_ARM_IQ80310
> >  ecosconfig tree
> >  make
> >
> > The resulting rom causes the board (as well as the entire PC that it's
> > plugged into) to lockup.  If I do not remove CYGPKG_DEVS_ETH_ARM_IQ80310
> > the resulting image works fine.
>
> And if you build an application without this package (or the TCP/IP stack)
> do breakpoints now work?

No.  If I remove CYGPKG_DEVS_ETH_ARM_IQ80310 with "ecosconfig remove 
CYGPKG_DEVS_ETH_ARM_IQ80310" for the *bootrom* build and build the bootrom, 
the resulting bootrom image causes the pci bus to crash the PC the IQ80310 is 
plugged into. 

Leaving CYGPKG_DEVS_ETH_ARM_IQ80310 in the bootrom leaves me with the same 
situation before, downloading an application that is compiled to include the 
NET package causes GDB to fail.  By "causing GDB to fail" I mean that when I 
hit the breakpoint at "main" and hit "continue" or hit "step" the code seemed 
to go into la-la land.  If, however, I disable the breakpoint at "main" the 
code produces the desired output and workes correctly.

I have since found the source of the "GDB" failure.  It appears to really be 
an ethernet driver failure corrupting memory.  In the driver "if_iq80310.c", 
the call to ResetTxRing fails on the 10th iteration of the for loop.  I 
haven't traced it exactly, but I am doing it now.  It may be that the 
MAX_TX_DESCRIPTORS variable is incorrect but I haven't determined exactly 
what it going on yet.  However, I can tell you that if I disable the 
following functions:

InitRxRing
ResetRxRing
InitTxRing
ResetTxRing

That GDB works fine and I'm able to step through code with no problems except 
of course the ethernet driver doesn't work which is to be expected.

I will continue debug to determine the exact error and contact you in private 
email if that is OK with you.  You are right, this discussion is too specific 
for the general list and I shouldn't be fillings people's mail boxes with it. 
Sorry everybody.

> Can you try the old redboot, but _enabling_ stubs in your application i.e.
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS

I will do that as soon as I have time

> Even if there was some sort of incompatibility between your hardware and
> the eth driver, I wouldn't expect it to affect breakpoints.

I cannot disagree with you there, I can only tell you what I am seeing.

I will stop bothering the list  for now and find out what is happening and 
let you know what's going on as soon as I know.  This bug seems to only 
appear in my configuration.  Perhaps I am using the incorrect driver but the 
name certainly sounds right.

> Jifl

In any case, thank you very much for your help.  You've already given me more 
support than I ever found with vxWorks which is why we're not using them.

Thank you,
-Richard Wicks