More on MCF5307C3 - NE2000 network driver

[gregory.menke at gsfc.nasa.gov]

Chris Xenophontos writes:
 > Thanks, Greg-
 > there are printf's, that indicate when the daemon wakes up(TX or RX
 > interrupt).  I hooked up a scope, and noticed that when the network task
 > quits, the interrupt is no longer asserted by the DM9008 chip -- normally,
 > you can see IRQ3 pulse low, i.e, during network activity.  When it quits,
 > IRQ3 no longer pulses but stays high.  
 > 
 > Now I'm wondering if the ISR (ns8390_interrupt_handler) is getting trashed
 > or if the DM9008 chip is being reset somehow(??) and not generating the
 > interrupt. We have several boards that behave exactly the same with this
 > application. 
 > 

My guess is the isr isn't getting the hardware set up for the next
interrupt when it exits.  I'd guess the network task is sitting there
waiting for the next wakeup- either a rx interrupt or a tx from the
stack.

I don't know how the ne2k arranges packet descriptors et al, but
perhaps it wants a circular list of packet descriptors and the list
the driver is supplying isn't, so the controller runs off the end and
quits.  I had quite a time with that sort of thing when I was working
on the elnk and dec21140 drivers...

Gregm



 >   
 > 
 > -----Original Message-----
 > From: gregory.menke at gsfc.nasa.gov [mailto:gregory.menke at gsfc.nasa.gov] 
 > Sent: Wednesday, July 07, 2004 9:56 AM
 > To: Chris Xenophontos
 > Cc: rtems-users at rtems.com
 > Subject: More on MCF5307C3 - NE2000 network driver
 > 
 > Chris Xenophontos writes:
 >  > Hello, 
 >  > 
 >  > A few weeks ago, we had successfully (for the most part) integrated the
 >  > NE2000 driver to the Coldfire MCF5307C3 Board Support package.  We are
 > able
 >  > to send/receive application data through the network to our board. 
 > However,
 >  > it appears that the either the receive or transmit daemon in ns8390.c
 > quits
 >  > after varying lengths of time.  When that happens, ping times-out, and of
 >  > course, no data is received/sent to the network.  No other error messages
 >  > are generated ( i.e, overflow, mbuf, ).
 >  > 
 >  > We have tried hard-coding values for mbuf and mbuf clusters in
 >  > rtems_bsdnet_config, using values up to 256K for mbufs, and 512K for mbuf
 >  > clusters. 
 >  >  
 >  > CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is currently set to 30. 
 > Increasing
 >  > it to 40 doesn’t help.  NETWORK_TASK_PRIORITY is 80, and the priority of
 > our
 >  > application task that reads (blocks) on the socket is 220.
 >  > 
 >  > Simply stopping and restarting the application, i.e, through the debugger
 >  > will re-initialize the entire application, but the network remains
 >  > unresponsive.  To get the network application to respond again, we need
 > to
 >  > do a hard reset of the board.
 >  > 
 >  > Is there some configuration parameter that I’m missing?
 >  > 
 >  > Thanks,
 >  > Chris Xenophontos
 >  > cxenophontos at hammers.com
 > 
 > Have you put printk's in the two daemons to see if they're waking up?
 > It sounds sort of like a deadlock with the network semaphore or
 > if_state.
 > 
 > Gregm
 > 
 >