This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
CS8900A driver
- To: "Ecos" <ecos-discuss at sourceware dot cygnus dot com>
- Subject: [ECOS] CS8900A driver
- From: "Jurica Baricevic" <jura at INTESIS dot hr>
- Date: Tue, 3 Oct 2000 14:59:16 +0200
Hi!
I am using an MIPS based board (r3041) and running eCos 1.3.1 + TCP/IP stack
(taken from CVS after some bugs were fixed) on it. Ethernet driver is the
same as 'if_edb7xxx.c' and it is working quite good. The problem which
bothers me is that I managed to get 'transmitter not ready' in cs8900_send()
function. Namely, I put the following code in cs8900_send() (after issuing a
command and reading bus status register, and before putting data into the
buffer):
(...)
if (!(stat & PP_BusStat_TxRDY))
{
diag_printf("CS8900: Eth. Transmitter not ready\n");
}
(...)
This code informed me that TxRDY was not set during very intensive testing
and high network traffic, but unfortunately after the notification I was not
able to communicate with my board any more(via Ethernernet). I do not know
is this due to strange state of CS8900A state machine, because of some
presumptions in driver/protocol code, or because of some other reason.
Moreover, I noticed the problem for only 3 times in a few months.
This problem seems quite odd to me.
Since I am not so acquainted with CS8900/driver, I wonder if this chip state
is possible at all in this driver?
Could I use some simple mechanism to handle this peculiar state? Namely,
could I issue something like a:
CS8900_TxCMD = PP_TxCmd_Force;
CS8900_TxLEN = 0;
and then safely exit from the cs8900_send()? Is it necessary to perform any
other 'house keeping' operation before returning from function (i.e. set
cpd->txbusy to 0, or call eth_drv_tx_done())?
One more question:
I do not see any error handling in cs8900_TxEvent function. What would
happen if an Tx error occurred?
Thanks in advance,
Jura