From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4659 invoked by alias); 24 Aug 2011 14:11:10 -0000 Received: (qmail 4649 invoked by uid 22791); 24 Aug 2011 14:11:07 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 24 Aug 2011 14:10:53 +0000 Received: (qmail 20512 invoked by uid 0); 24 Aug 2011 14:10:51 -0000 Received: from 80.75.119.105 by www031.gmx.net with HTTP; Wed, 24 Aug 2011 16:10:51 +0200 (CEST) Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Date: Wed, 24 Aug 2011 14:11:00 -0000 From: "Philipp Meier" In-Reply-To: Message-ID: <20110824141051.115980@gmx.net> MIME-Version: 1.0 References: <20110824103404.51600@gmx.net> To: "ecos discuss" X-IsSubscribed: yes 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: Re: [ECOS] ecos-3.0 current stm32 bug? X-SW-Source: 2011-08/txt/msg00041.txt.bz2 -------- Original-Nachricht -------- > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST) > Von: Sergei Gavrikov > An: Philipp Meier > CC: ecos-discuss@ecos.sourceware.org > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug? > On Wed, 24 Aug 2011, Philipp Meier wrote: > > > Hi all > > > > I have a firmware split into two parts: > > 1. a "bootloader" > > 2. a "application" > > > > I now need to move from Windows (cygwin) development environment to > > Linux development environment and at the same time use the current > > ecos version (i.e. what I get when I clone the ecos mercurial > > repository) instead of the "original" (back in 2009) ecos-3.0 version. > > > > The situation is now as follows: > > 1. I download (to my stm32 device) the Linux/ecos-current built > > "bootloader" > > 2. I download (to my stm32 device) the Linux/ecos-current built > > "application" > > 3. I start the application and in line 187 of file > > 'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to > > 'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr' > > function! > > > > To analyze the problem I then: > > 4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built > > "bootloader" > > 5. Still having the Linux/ecos-current built "application" > > 6. And in line 187 (of the above mentioned file) it branches (as it > > should) to 'hal_switch_state_vsr' and the application is starting up > > and running fine! > > > > Who can give me a hint about > > * what has been changed in ecos-current cortexm stm32 that could > > cause this problem > > Hi Philipp, > > I think you can use Mercurial for that > > % hg tags | grep v3 > ecos-v3_0-branchpoint 2821:b5a12bb6a634 > > % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch | less > -FRSX > > or (may be) > > % hg log --patch -r ecos-v3_0-branchpoint:tip \ > packages/hal/cortexm/arch/current/src/hal_misc.c | less -FRSX > > etc. > > > * or what else I could analyze to find out why ecos-current (built on > > Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin I > > also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric) > > Also you would check the Linux build for ecos-3.0 codebase > > # get old (working) code > % hg update ecos-v3_0-branchpoint > > Rebuild your loader and application under Linux and try it (use fresh > directories for builds). After all do not forget up-to-date eCos HG > repository (hg update default). > > Feel free to submit a bug report (if you'll find something) via eCos > Bugzilla System http://bugs.ecos.sourceware.org/ > > > Sergei > > > Regards > > Philipp Hello Sergei and others Thanks a lot for your tips about how to find out the differences between the versions. I now went a step back and built (under Linux) my "bootloader" and my "application" under Linux using the same ecos sources and configuration files as when I built them under Windows/cygwin. Therefore - I wanted to see if the problem comes from building under Linux, or from changes in the ecos stm32 parts (or any other ecos parts). But - I have the same problem as described above; i.e. the problem must be somehow in my Linux toolchain? Therefore my question now is: Can anybody give me some background information about how the "__asm__ volatile( "swi" )" statement in line 188 of packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187 in packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-current) is interpreted on stm32? What could be the reason that it does not jumps to "hal_switch_state_vsr" but instead jumps to "hal_default_exception_vsr"? The lines where the different behaviour is look like this: hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] = (CYG_ADDRESS)hal_switch_state_vsr; __asm__ volatile( "swi" ); ... In the good case these leads to a jump/branch to hal_switch_state_vsr and in the bad case it jumps/branches to hal_default_exception_vsr and therefore my application does not starts up. Thanks for any help. Philipp -- P.S.: Sorry Sergei - I did not mean to reply directly to you but like this to the mailing list. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss