From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28924 invoked by alias); 23 May 2006 11:34:52 -0000 Received: (qmail 28915 invoked by uid 22791); 23 May 2006 11:34:51 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 May 2006 11:34:47 +0000 Received: by snape.ecoscentric.com (Postfix, from userid 99) id 2A79A2C007; Tue, 23 May 2006 12:09:23 +0100 (BST) Received: from [192.168.7.9] (dargo.barn.ecoscentric.com [192.168.7.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by snape.ecoscentric.com (Postfix) with ESMTP id 58431DD41D8; Tue, 23 May 2006 12:09:20 +0100 (BST) Message-ID: <4472ED5F.8040801@jifvik.org> Date: Tue, 23 May 2006 11:34:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Somerton Cc: ecos-maintainers@ecos.sourceware.org Subject: Re: posting requests for help References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on snape.ecoscentric.com X-Spam-Level: Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2006-05/txt/msg00004.txt.bz2 David Somerton wrote: > Hello, > > where i work eCos is used. > there is now nobody left from the original people who chose this OS. > we may not subscribe to mailing lists. > i read the faq on sending to the list without subscribing, but could > not understand it at all. It's quite simple - just send to the list, but warn people to include you in their replies (although you can also view the online web archives in case someone didn't). > i only want to ask a question, why do you make it so difficult. > not everybody is a ecos or linux genius. I think thousands of subscribers and larger numbers of eCos users can testify to the fact you don't need to be a genius. > the question, in case you feel like posting it for me is > > ASSERT FAIL: <19>serial.c[1128]serial_data_xmt_req() Attempting new > block transfer while another is running > ASSERT FAIL: <19>serial.c [1128] serial_data_xmt_req() > Attempting new block transfer while another is running > > this happens when enabling rts/cts handshaking. > > I have tried looking at the source for serial.c, but i cannot > comprehend it. > It seems extremly complex for a serial driver. It's a generic driver supporting a variety of hardware features, in a variety of ways. Bear in mind that if no-one is reporting the same problem as you, the chances are that your problem is not in generic code. It is probably in your underlying hardware driver. It is worth noting that in your case, whoever wrote the underlying hardware driver chose to use block transfer mode, not the more normal character-by-character mode. That already makes it more complex than a standard serial driver. I think I could easily infer from the message that serial_data_xmt_req() has been called when another xmt block transfer is running. The underlying driver should be following every serial_data_xmt_req() call with serial_data_xmt_done(), but this time it is clearly doing serial_data_xmt_req() twice instead which is wrong, hence the assert. Try setting breakpoints on serial_data_xmt_req, serial_data_xmt_done and cyg_assert_fail (to catch the state when the assert triggers) and analyse what you see, bearing in mind that it is the underlying driver that you really need to be debugging, not the generic serial.c stuff. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine