From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6255 invoked by alias); 3 Dec 2012 00:01:32 -0000 Received: (qmail 6238 invoked by uid 22791); 3 Dec 2012 00:01:31 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from p02c12o144.mxlogic.net (HELO p02c12o144.mxlogic.net) (208.65.145.77) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 00:01:26 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o144.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 4dbebb05.0.34826.00-2396.59833.p02c12o144.mxlogic.net (envelope-from ); Sun, 02 Dec 2012 17:01:26 -0700 (MST) X-MXL-Hash: 50bbebd64a6c1f32-ab8a0e5321ded2c0a9eb3c09d6214fba67c14293 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id 5F1D0740A5; Sun, 2 Dec 2012 16:01:24 -0800 (PST) Received: from [192.168.0.119] (75-163-186-131.clsp.qwest.net [75.163.186.131]) by smtpauth1.linear.com (Postfix) with ESMTPSA id E81A4740A2; Sun, 2 Dec 2012 16:01:23 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Jones In-Reply-To: <50BB299F.5070404@siva.com.mk> Date: Mon, 03 Dec 2012 00:01:00 -0000 Cc: eCos Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> To: Ilija Kocho X-AnalysisOut: [v=2.0 cv=cdRlWA/M c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=gTASQVg5WCMA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=MqDINYqSAAAA:8 a=l9cmVeDug7kA:10 a=O8eIFpr9] X-AnalysisOut: [AAAA:8 a=CCpqsmhAAAAA:8 a=Td_wPcBsQaFFfRd5tPcA:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10 a=2MmS2GirHJN9Vosk:21 a=ACW4xZMG3sKDHVdQ:21] X-MAIL-FROM: 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] Kinetis CYG_HAL_STARTUP_VAR conflict X-SW-Source: 2012-12/txt/msg00011.txt.bz2 IIila, I implemented what you sent, and ended up with an infinite loop of SIGTRAPs= . So I am stuck, but at least I have Insight/gdb running and can see what t= he code is doing. But, I don't know enough about the memory usage to know w= hat is wrong. DETAILS ------------ I made some progress. I updated the files, and then did the following: 1) Put memory checking back into the RedBoot image 2) In the application config, changed to RAM. Built the app, etc. 3) telnet into RedBoot 4) Load with load -v -h x.x.x.x hello.srec 5) go The command line then becomes unresponsive, and nothing prints. I then change printf to diag_printf, just in case that is the problem. Same= results. So then I compile up Insight so I have a debugger and then: A) Connect to RedBoot with Insight B) Load image Loading section .rom_vectors, size 0x8 lma 0x1fffe400 Loading section .ARM.exidx, size 0x10 lma 0x1fffe408 Loading section .text, size 0x6930 lma 0x1fffe418 Loading section .rodata, size 0x2004 lma 0x20004d48 Loading section .data, size 0x1b0 lma 0x20006d58 Start address 0x1fffe419, load size 35580 I see a break point at the first line in main: int main(void) { *** diag_printf("Hello 1, eCos world!\n"); diag_printf("Hello 2, eCos world!\n"); return 0; } C) Tell image to continue via Control | Continue The debugger then stops in file vectors.S at line 101: 86 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 87 // Fake entry point. 88 // 89 // The ELF file entry point points here. When loading an executable 90 // via RedBoot/Stubs or via JTAG the PC will be set to this address. 91 // The code here sets up the SP and branches to the reset VSR in 92 // emulation of the hardware reset behaviour. 93=09 94 .align 2 95 .global reset_vector 96 .thumb 97 .thumb_func 98 .type reset_vector, %function 99 reset_vector: 100=09 - 101 ldr sp,=3Dhal_startup_stack - 102 b hal_reset_vsr 103=09 104 .pool Any time I do a continue, I stop at this line 101 and the gdb console says: Program received signal SIGTRAP, Trace/breakpoint trap. reset_vector () at /opt/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src= /vectors.S:101 My intuition is that "b" means branch, and the hal_reset_vsr either is poin= ting to reset_vector, or something else causes the SIGTRAP, leading back he= re. At this point I have to admit ignorance of how traps work. But moving forwa= rd, I did a step next line in the debugger. This resulted in an infinite wa= it for a response that never came. So I closed Insight and stopped. A little research says that SIGTRAP is the processor noting an instruction = was hit, and then GDB should handle the breakpoint. My interpretation of the GDB console is that the target trapped at vectors.= S:101, but I used the debugger to put a break point at the first instructio= n in main. I suppose it is possible this is where it thinks the trap goes... but I am guessing something is in the wrong place, like loading the program= image stepped on part of RedBoot's SRAM code or tables. Any insights? Mike On Dec 2, 2012, at 3:12 AM, Ilija Kocho wrote: > Hi Mike >=20 > On 01.12.2012 22:07, Michael Jones wrote: >> BACKGROUND >> ---------------------- >>=20 >> I am having a little bit of trouble trying to get my first hello world a= pp on a K60 Tower Board. >>=20 >> I have RedBoot running from ROM and I can ping the ethernet port, so pre= sumably I will eventually get GDB to talk to it. >>=20 >> I am having trouble building an initial app that uses the ROM monitor. F= ollowing the example in the eCos book, I went hunting for CYGSEM_HAL_USE_RO= M_MONITOR, enabled it and then set startup to SRAM. This seems the obvious = way to run and debug. >>=20 >> PROBLEM >> -------------- >>=20 >> I am getting a conflict I don't know how to resolve. I have set CYG_HAL_= STARTUP_VAR =3D SRAM. This results in CYG_HAL_STARTUP =3D SRAM by calculati= on. >>=20 >> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HAL_= STARTUP =3D=3D RAM > SRAM and RAM startups are not the same. RAM startup is intended for > using under control of RedBoot and has some special properties: RAM, > unlike other startup types uses RedBoot's vectors, etc... >=20 > SRAM startup is kind of "stand-alone" in a way it does not depend on > RedBoot (but depends on JTAG debugger) >=20 >> QUESTIONS >> ----------------- >>=20 >> 1) Can I ignore this conflict and get the monitor and app to work? > I'm afraid not because, SRAM startup collides with RedBoot. >>=20 >> 2) Is there a better approach? > The right approach is to create RAM startup. It could live on variant > level and be available to all Kinetis platforms (though some may have > too little memory to utilize it). > The attached patches should produce proper variant-level RAM startup. >=20 > I did not add it from beginning since I consider internal SRAM too > little for practical work, seems that other people have different view. > You are not the first to look for. > This being said, I am considering to add this startup to the main > repository. Would you open a Bug on Bugzilla? >=20 >>=20 >> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply an = example config project that works that I can look at? > You may want to try this: > http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001623 but beware, it > is experimental, and at present it may be broken as it's not synced with > recent Kinetis patches. > Take care not to lock your Kinetis flash - You have been warned :) >=20 > I hope this helps and I would appreciate feedback. >=20 > Regards > Ilija > --=20 > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss