* Re: [ECOS] CS8900A w/ARM locking condition
2006-05-25 8:32 ` Deak, Ferenc
@ 2006-05-25 8:56 ` Daniel Morris
2006-05-25 10:20 ` Deak, Ferenc
2006-05-25 12:36 ` Alfonso Amato - Sintecnos srl
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Morris @ 2006-05-25 8:56 UTC (permalink / raw)
To: Deak, Ferenc; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] CS8900A w/ARM locking condition
2006-05-25 8:32 ` Deak, Ferenc
2006-05-25 8:56 ` Daniel Morris
@ 2006-05-25 12:36 ` Alfonso Amato - Sintecnos srl
1 sibling, 0 replies; 5+ messages in thread
From: Alfonso Amato - Sintecnos srl @ 2006-05-25 12:36 UTC (permalink / raw)
To: ecos-discuss; +Cc: Deak, Ferenc
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
^ permalink raw reply [flat|nested] 5+ messages in thread