From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 372 invoked by alias); 24 Jan 2014 08:57:09 -0000 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 Received: (qmail 363 invoked by uid 89); 24 Jan 2014 08:57:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: tetra.codeconfidence.com Received: from tetra.codeconfidence.com (HELO tetra.codeconfidence.com) (94.229.66.225) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 08:57:06 +0000 Received: from cog.dallaway.org.uk (cpc1-cmbg10-0-0-cust34.5-4.cable.virginm.net [81.102.132.35]) by tetra.codeconfidence.com (Postfix) with ESMTP id 76E46234C013; Fri, 24 Jan 2014 08:57:04 +0000 (GMT) Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id s0O8v3fa007200; Fri, 24 Jan 2014 08:57:03 GMT Message-ID: <52E22ADF.1040109@dallaway.org.uk> Date: Fri, 24 Jan 2014 08:57:00 -0000 From: John Dallaway User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130807 Thunderbird/17.0.8 MIME-Version: 1.0 To: Samuel Charnet CC: eCos Discussion References: <52E14C04.30308@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ECOS] Re: STM32 ROMINT don't run X-SW-Source: 2014-01/txt/msg00025.txt.bz2 Hi Samuel On 23/01/14 18:02, Samuel Charnet wrote: > John Dallaway wrote: > >> You may be observing the following issue: >> >> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864 >> >> Try modifying hal/cortexm/arch/current/src/hal_misc.c to read as follows: >> >>> #if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMINT) >>> // Relocate data from ROM to RAM > > Thanks for your quick answer. > > I had a hope but it is not enought, it still doesn't run. > > the stack is different : > > (gdb) target remote :3333 > Remote debugging using :3333 > 0x00000000 in ?? () > (gdb) c > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > stm32f4x.cpu -- clearing lockup after double fault > Program received signal SIGINT, Interrupt. > 0x00000000 in ?? () > (gdb) where > #0 0x00000000 in ?? () > #1 0x08001d3c in Cyg_Exception_Control::deliver_exception > (this=, exception_number=, > exception_info=) > at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx:234 > #2 0x0800005e in hal_default_exception_vsr () at > /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184 > #3 0x0800005e in hal_default_exception_vsr () at > /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) If you have not already done so, disable compiler optimisation by removing "-O2" from the CYGBLD_GLOBAL_CFLAGS option. Also enable CYGPKG_INFRA_DEBUG. You should then be able to step into your code from system reset and see where the exception is triggered. Note that STM3240G-EVAL ROMINT startup is similar to STM32F4-Discovery ROM startup which is working fine. So I don't think there is a major problem here. Check all references to "CYG_HAL_STARTUP == ROM" and "CYG_HAL_STARTUP_ROM". Modify these expressions if the code they control is also relevant for ROMINT startup. Good luck with your debugging... John Dallaway eCos maintainer http://www.dallaway.org.uk/john -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss