This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CS8900A w/ARM locking condition


Thanks!

I tried to make more tests and read more literature about and I found out the following:

1. The CS8900A seems not to work correctly if used in 8 bit mode with the interrupt: the AN181 from cirrus/crystal says that this should not be used and, in case of heavy traffic, the int gets hung and you have to reset the chip and restart it in order to have it back working finely.

2. When removing the interrupt and using the ecos in polling mode, it happens what I said and you answered me: after some time of heavy traffic, the Rdy4TxNOW pin doesn't get high anymore and the chip needs to be manipulated in some time. On my code, instead of resetting it while calling a subset of instruction of the init in the palce you suggested, I used a new send with the "force" bit set and a length of 0. This seems to work fine also after a big amount of traffic while keeping the board on for some days.

I just ask myself a question: reading the code, it seems that the init is meant to be made with interrupt regardless of the define, while the send is made to be done in polling regardless the define.

Moreover, I had to change the define position as it was strangely written (a define of noint inside another define of noint that excludes the first).

When I'll have a settled down code, I'll forward it for updating the tree.

Alfonso

Deak, Ferenc wrote:
On Wed, 17 May 2006 19:49:43 +0200
Alfonso Amato - Sintecnos srl <a.amato@sintecnos.com> wrote:

Has someone experienced what follows and has some workaround?

The board is a custom made by us, and uses a Sharp LH75400 with a Cirrus CS8900A. The ecos is tailored for this board and uses free_bsd stack. The application is running in some tasks with preemptive kernel.

I see that after some time working, mainly if there is some traffic on a normal window ethernet environment, the tcp/ip communication locks. I see the int pin locked high. In another testbed (without seeing the int pin) i see the system locking on BusStat check while loop (the getreg says that the address 312 decimal returns 0x0018 (instead of 0x0118, that's the chip is ready to send NOW).

Any help, please?

Alfonso Amato
Sintecnos


I experienced endless loops in dev/eth/cl/cs8900a/current/src/if_cs8900a.c cs8900a_send(). See line 508 in the current CVS. You have to put some kind of timeout
handling in the following loop:


---------------------------
508:    do {
509:        stat = get_reg(base, PP_BusStat);
510:    } while (!(stat & PP_BusStat_TxRDY));
---------------------------

personally I changed it to

----------------------------
    timeout = 0;
#ifdef CYGPKG_KERNEL
    starttime = cyg_current_time();
#endif
    do {
        stat = get_reg(base, PP_BusStat);
	timeout++;
#ifndef CYGPKG_KERNEL
	if (timeout > 100000) {
	    //diag_printf("Timeout on the cs8900 driver!\n\n\n\n\n");
	    return;
	}
#else
	if (timeout > 100) {
	    //diag_printf("#\n");
	    timeout = 0;
	    if (starttime + 3 * 100 < cyg_current_time()) {
		//diag_printf("Timeout on the cs8900 driver!\n\n\n\n\n");
		return;
	    }
	}
#endif
    } while (!(stat & PP_BusStat_TxRDY));
------------------------------

where the two new variable is:
 int timeout;
 cyg_tick_count_t starttime;

Later I created a cs8900_reset function from a part of cs8900_init, and I called
this function before init, but now I'm simply return, I will look after it...

Hope this helps,
Ferenc Deak

PS
Ecos maintaners, please consider it as a bug report. The solution is not perfect, but the something have to be done with this loop.






-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]