[ECOS] CS8900A w/ARM locking condition

[ECOS] CS8900A w/ARM locking condition

[Alfonso Amato - Sintecnos srl]

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

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

Re: [ECOS] CS8900A w/ARM locking condition

[Deak, Ferenc]

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

Re: [ECOS] CS8900A w/ARM locking condition

[Daniel Morris]

On Thu, May 25, 2006 at 10:34:55AM -0500, Deak, Ferenc wrote:
> On Wed, 17 May 2006 19:49:43 +0200
> Alfonso Amato - Sintecnos srl <a.amato@sintecnos.com> wrote:

<snip>
> 
> 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.

See http://ecos.sourceware.org/problemreport.html for help on how you
can do this.

 Daniel


%<----------------------------------------------------------------------
  Daniel Morris - Sales & Marketing Director
  eCosCentric - The eCos and RedBoot experts
  Tel: +44 1223 245 571 - info@eCosCentric.com
  DDI: +44 1269 591 171 - danielm@eCosCentric.com


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

Re: [ECOS] CS8900A w/ARM locking condition

[Deak, Ferenc]

On Thu, 25 May 2006 09:58:29 +0100
Daniel Morris <danielm@eCosCentric.com> wrote:

> > 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.
> 
> See http://ecos.sourceware.org/problemreport.html for help on how you
> can do this.

Thank you, I've done it.

feco


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

Re: [ECOS] CS8900A w/ARM locking condition

[Alfonso Amato - Sintecnos srl]

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