From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18591 invoked by alias); 4 Dec 2012 02:18:52 -0000 Received: (qmail 18580 invoked by uid 22791); 4 Dec 2012 02:18:51 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from p02c12o142.mxlogic.net (HELO p02c12o142.mxlogic.net) (208.65.145.75) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Dec 2012 02:18:45 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o142.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 48d5db05.0.30677.00-2341.71816.p02c12o142.mxlogic.net (envelope-from ); Mon, 03 Dec 2012 19:18:45 -0700 (MST) X-MXL-Hash: 50bd5d8540a29b23-3d7bb90607c8032dc69714adeb3e45988cc83a84 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id A7E95740A6; Mon, 3 Dec 2012 18:18:43 -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 38CD1740A5; Mon, 3 Dec 2012 18:18:43 -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: <50BCF9AD.7030309@siva.com.mk> Date: Tue, 04 Dec 2012 02:18:00 -0000 Cc: eCos Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <194934E0-13F3-43AF-97F0-C62EFDAA0B37@linear.com> References: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> <50BCF9AD.7030309@siva.com.mk> To: Ilija Kocho X-AnalysisOut: [v=2.0 cv=GIq/5JxK 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=Yzk4GUZN6LR2K_Rb2fgA:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10 a=fHUeddF2_2nBl1CY:21 a=Id111dQEU_QhzIfw: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/msg00013.txt.bz2 IIija, I used your version of the RedBoot project and got the same results. Perhap= s you can take a look at my application project and see if I have done some= thing wrong. If you have a hello world project that works, I could run it a= nd see if it works here. Mike On Dec 3, 2012, at 12:12 PM, Ilija Kocho wrote: > Mike >=20 > I need insight in your RedBoot configuration. It would help if you send > me the ECM file (File->Export...) >=20 > I also attach the ECM file of my RedBoot that works for small "Hello > world" app. > Importing it in a _fresh_ RedBoot configuration should give you same > configuration as mine (provided that you have patched the latest SVN > version). > I tested it for loading from RedBoot prompt but not for GDB since at > present I am away from my lab. > Load works for both SREC and ELF files. >=20 > FYI you can also initialize RedBoot configuration (fconfig -i) so you > won't need to enter tftp host every time. >=20 > I hope this will work for you. >=20 > Ilija >=20 >=20 > On 03.12.2012 01:01, Michael Jones wrote: >> IIila, >>=20 >> I implemented what you sent, and ended up with an infinite loop of SIGTR= APs. So I am stuck, but at least I have Insight/gdb running and can see wha= t the code is doing. But, I don't know enough about the memory usage to kno= w what is wrong. >>=20 >> DETAILS >> ------------ >>=20 >> I made some progress. I updated the files, and then did the following: >>=20 >> 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 >>=20 >> The command line then becomes unresponsive, and nothing prints. >>=20 >> I then change printf to diag_printf, just in case that is the problem. S= ame results. >>=20 >> So then I compile up Insight so I have a debugger and then: >>=20 >> A) Connect to RedBoot with Insight >> B) Load image >>=20 >> 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 >>=20 >> I see a break point at the first line in main: >>=20 >> int main(void) >> { >> *** diag_printf("Hello 1, eCos world!\n"); >> diag_printf("Hello 2, eCos world!\n"); >> return 0; >> } >>=20 >>=20 >> C) Tell image to continue via Control | Continue >>=20 >> The debugger then stops in file vectors.S at line 101: >>=20 >> 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 >>=20 >>=20 >> Any time I do a continue, I stop at this line 101 and the gdb console sa= ys: >>=20 >> Program received signal SIGTRAP, Trace/breakpoint trap. >> reset_vector () at /opt/ecos/ecos-3.0/packages/hal/cortexm/arch/current/= src/vectors.S:101 >>=20 >> My intuition is that "b" means branch, and the hal_reset_vsr either is p= ointing to reset_vector, or something else causes the SIGTRAP, leading back= here. >>=20 >> At this point I have to admit ignorance of how traps work. But moving fo= rward, I did a step next line in the debugger. This resulted in an infinite= wait for a response that never came. So I closed Insight and stopped. >>=20 >> A little research says that SIGTRAP is the processor noting an instructi= on was hit, and then GDB should handle the breakpoint. >>=20 >> My interpretation of the GDB console is that the target trapped at vecto= rs.S:101, but I used the debugger to put a break point at the first instruc= tion in main. I suppose it is possible this is where it thinks the trap goe= s... >>=20 >> but I am guessing something is in the wrong place, like loading the prog= ram image stepped on part of RedBoot's SRAM code or tables. >>=20 >> Any insights? >>=20 >> Mike >>=20 >>=20 >> On Dec 2, 2012, at 3:12 AM, Ilija Kocho wrote: >>=20 >>> 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= app on a K60 Tower Board. >>>>=20 >>>> I have RedBoot running from ROM and I can ping the ethernet port, so p= resumably I will eventually get GDB to talk to it. >>>>=20 >>>> I am having trouble building an initial app that uses the ROM monitor.= Following the example in the eCos book, I went hunting for CYGSEM_HAL_USE_= ROM_MONITOR, enabled it and then set startup to SRAM. This seems the obviou= s way to run and debug. >>>>=20 >>>> PROBLEM >>>> -------------- >>>>=20 >>>> I am getting a conflict I don't know how to resolve. I have set CYG_HA= L_STARTUP_VAR =3D SRAM. This results in CYG_HAL_STARTUP =3D SRAM by calcula= tion. >>>>=20 >>>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HA= L_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. >>>> 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 >>>> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply a= n 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 >>=20 >=20 > --=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