From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12619 invoked by alias); 25 May 2006 08:32:16 -0000 Received: (qmail 12602 invoked by uid 22791); 25 May 2006 08:32:13 -0000 X-Spam-Check-By: sourceware.org Received: from mail.interware.hu (HELO mail.interware.hu) (195.70.32.130) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 08:31:44 +0000 Received: from demo.scomplex.com ([195.70.34.240] helo=mail.stp.hu) by mail.interware.hu with esmtp (Exim 4.52 #1 (Debian)) id 1FjBFt-0005qg-EY for ; Thu, 25 May 2006 10:31:41 +0200 Received: from localhost [10.1.1.2] by Proxy+; Thu, 25 May 2006 10:30:57 +0200 for Date: Thu, 25 May 2006 08:32:00 -0000 From: "Deak, Ferenc" To: ecos-discuss@ecos.sourceware.org Message-Id: <20060525103455.0746d875.ferenc.deak@stp.hu> In-Reply-To: <446B6237.1080508@sintecnos.com> References: <446B6237.1080508@sintecnos.com> X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.8.9; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] CS8900A w/ARM locking condition X-SW-Source: 2006-05/txt/msg00205.txt.bz2 On Wed, 17 May 2006 19:49:43 +0200 Alfonso Amato - Sintecnos srl 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