From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23418 invoked by alias); 23 Oct 2009 11:54:30 -0000 Received: (qmail 23409 invoked by uid 22791); 23 Oct 2009 11:54:29 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_05 X-Spam-Check-By: sourceware.org Received: from firewall.logopak.de (HELO Firewall.logopak-it.com) (212.224.3.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 11:54:23 +0000 Received: from [10.1.3.18] (port=3198 helo=10.1.3.18) by Firewall.logopak-it.com with esmtp (Exim 4.69) (envelope-from ) id 1N1Iih-0003IW-01 for ecos-discuss@ecos.sourceware.org; Fri, 23 Oct 2009 13:54:11 +0200 Received: from il [10.1.60.50] by logopak.de with David.fx (0293.454946444646504A4C53); 23 Oct 2009 11:54:10 UT From: Iris Lindner Date: Fri, 23 Oct 2009 11:54:00 -0000 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200910231355.49338.ilindner@logopak.de> Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: FLASH API v.2 and interrupts X-SW-Source: 2009-10/txt/msg00149.txt.bz2 Hi Bart, here comes a small summary for we could finally solve our problem concerning FLASH crashes and interrupt serving (for everyone who might come over similar problems). Thank you very much again for your kind help!! We stayed at V1 FLASH API but now we leave interrupts always enabled (just commented out the approp. lines on API level). As consequence CAN interrupts can always be served in time and the bus stays alive. To prevent competing FLASH access we use a semaphore on next higher level. So every routine which uses FLASH API _must_ obtain semaphore first or wait for it if taken. Interrupts must not be disabled on higher level in relation to FLASH operations. These steps taken lead to positive tests without FLASH inconsistency or a broken CAN bus anymore. The reason for earlier problems was probably, as you suspected (or as you warned against), that there were three program part accessing FLASH which was not synchronized or organized with a mutex (I only knew one part for a long time). > Iris> As far as I understood the offsets are always added to the > Iris> actual block address to be erased (addr). But in the chip > Iris> documentation (we use a Spansion S29GL256P) it says that > Iris> offsets have to be added to base address of flash range. > > That is strange. The current code works on numerous AMD (now Spansion) > and compatible chips without problems. The datasheet will typically > include something like the following, hidden away in a footnote: > > "Address bits AMAX:A16 are don't cares for unlock and command > cycles, unless SA or PA required. (AMAX is the Highest Address > pin.)." I couldn't find a hint like that in data sheet for our chip, so this could be one reason why V2 didn't work. But I must admit that I didn't dig deeper into it for now... =) Thank you very much again, kind regards, Iris -- Iris Lindner Software Development Industrial Print and Apply Labelling www.Logopak.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