[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More on MCF5307C3 - NE2000 network driver
- Date: Wed, 7 Jul 2004 23:29:37 -0400 (EDT)
- From: gregory.menke at gsfc.nasa.gov (gregory.menke at gsfc.nasa.gov)
- Subject: More on MCF5307C3 - NE2000 network driver
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
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
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...
> -----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
> > to send/receive application data through the network to our board.?
> > it appears that the either the receive or transmit daemon in ns8390.c
> > 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.?
> > it to 40 doesn?t help.? NETWORK_TASK_PRIORITY is 80, and the priority of
> > 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
> > 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