From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18923 invoked by alias); 8 Jul 2005 14:08:36 -0000 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 Received: (qmail 18615 invoked by uid 22791); 8 Jul 2005 14:08:30 -0000 Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 08 Jul 2005 14:08:30 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1DqtWl-0000PU-00; Fri, 08 Jul 2005 16:08:27 +0200 Date: Fri, 08 Jul 2005 14:08:00 -0000 To: Will Wagner Cc: eCos Discussion Message-ID: <20050708140827.GA2640@lunn.ch> Mail-Followup-To: Will Wagner , eCos Discussion References: <42CE6EEB.1070309@carallon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CE6EEB.1070309@carallon.com> User-Agent: Mutt/1.5.9i From: Andrew Lunn Subject: Re: [ECOS] Mutex & Asserts during initialisation X-SW-Source: 2005-07/txt/msg00086.txt.bz2 On Fri, Jul 08, 2005 at 01:17:47PM +0100, Will Wagner wrote: > Hi All, > > I am trying to run with asserts on to test a couple of things. However > there seems to be a problem with the mutex check_this function has been > implemented. > > If anything tries to lock a mutex before the scheduler has been started > then an assert goes off. This is because when locking the mutex > Cyg_Thread::self() returns NULL. So in the check this function locked is > true but owner is NULL so it fails. > > This means that you can't use SPI or i2c before the scheduler starts. If > you have any driver that is initialised via static constructor that uses > either of those then the system asserts. An example of this would be the > DS1307 wallclock. > > How has anyone worked around this in the past? Humm, i think this is reasonable behaviour. Anything that tries to use a mutex must assume it can block. Otherwise why are you using a mutex! I think the solution for you is to also start the schedular in a static constructor. Just give it a higher priority than anything that needs the schedular enabled. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss