From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20534 invoked by alias); 10 Jun 2004 10:29:33 -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 20491 invoked from network); 10 Jun 2004 10:29:29 -0000 Received: from unknown (HELO icarus.sli-institute.ac.uk) (195.195.244.10) by sourceware.org with SMTP; 10 Jun 2004 10:29:29 -0000 Received: from sli-institute.ac.uk ([192.168.120.114]) by icarus.sli-institute.ac.uk with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 11:29:48 +0100 Message-ID: <40C837EC.1060601@sli-institute.ac.uk> Date: Thu, 10 Jun 2004 10:29:00 -0000 From: Henrik Mau User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 MIME-Version: 1.0 To: ecos-discuss@sources.redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2004 10:29:48.0721 (UTC) FILETIME=[DB48FA10:01C44ED5] Subject: [ECOS] Failure to run application X-SW-Source: 2004-06/txt/msg00094.txt.bz2 I have an ARM Integrator with an ARM7TDMI processor on it. Redboot has been built and seems to be running fine. I have built the twothreads example using a default build of eCos for ARM Integrator 7TDMI. After I have downloaded the program using Insight I step through the code using asm steps. When executing the platform setup, setting up LED and control vectors, an exception occurs and the program counter starts executing code in Cyg_Scheduler::unlock in the application although the scheduler has not started yet. It finally ends in a SIGBUS error somewhere in the scheduler code. When looking into the details of what the assembly code does I noticed some discrepancies between the source code in hal_platform_setup.h and the disassembled shown in Insight. Specifically, "mov" instructions shown in Insight are "ldr" instructions in the source code. Even stranger however, is that loading a value into a register using "mov" does not work. The value is not updated. Thinking that Insight might not be updating the contents of the register window properly I rewrote the exception handler for Redboot and dumped the registers to memory every time an exception happens. This showed that the registers do in fact not get updated. ldr r0,=INTEGRATOR_DBG_BASE ldr r1,=0 strb r1, [r0, #INTEGRATOR_DBG_LEDS_OFFSET] ldr r0, =INTEGRATOR_HDR_BASE ldr r1, [r0, #INTEGRATOR_HDR_CTRL_OFFSET] orr r1, r1, #INTEGRATOR_HDR_CTRL_REMAP str r1, [r0, #INTEGRATOR_HDR_CTRL_OFFSET] ldr r1, =INTEGRATOR_IRQCONT_BASE ldr r0, =0xFFFFFFFF str r0, [r1, #INTEGRATOR_IRQENABLECLEAR] str r0, [r1, #INTEGRATOR_FIQENABLECLEAR] ldr r0,=INTEGRATOR_DBG_BASE ldr r1,=0xF strb r1, [r0, #INTEGRATOR_DBG_LEDS_OFFSET] mov r0, #436207616 ; 0x1a000000 r0 retains the value 1 mov r1, #0 r1 retains the value 1 strb r1, [r0, #4] mov r0, #268435456 ; 0x10000000 r0 retains the value 1 ldr r1, [r0, #12] r1 gets a new value, but not the expected one orr r1, r1, #4 r1 becomes 0?? str r1, [r0, #12] mov r1, #335544320 ; 0x14000000 r1 retains the value 0 ldr r0, [pc, #1224] ; 0x40530 <_eCos_id+20> Exception happens when executing this instruction. Link register points to next instruction. str r0, [r1, #12] str r0, [r1, #44] mov r0, #436207616 ; 0x1a000000 mov r1, #15 strb r1, [r0, #4] The only explanation I can come up with is that the disassembled source code I shown is not correct and something entirely different takes place. I am at a loss as to what else it could be and would appreciate any help I can get. Kind regards, Henrik -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss