From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29515 invoked by alias); 4 Dec 2012 02:31:24 -0000 Received: (qmail 29418 invoked by uid 22791); 4 Dec 2012 02:31:21 -0000 X-SWARE-Spam-Status: No, hits=-3.0 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 p02c12o148.mxlogic.net (HELO p02c12o148.mxlogic.net) (208.65.145.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Dec 2012 02:31:08 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o148.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id b606db05.0.48675.00-2342.115781.p02c12o148.mxlogic.net (envelope-from ); Mon, 03 Dec 2012 19:31:08 -0700 (MST) X-MXL-Hash: 50bd606c78a2f61f-e71e71ade4496faa1e6195160dfd51238a057fc4 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id EC56C740A7; Mon, 3 Dec 2012 18:31:06 -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 7CE34740A5; Mon, 3 Dec 2012 18:31:06 -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: <194934E0-13F3-43AF-97F0-C62EFDAA0B37@linear.com> Date: Tue, 04 Dec 2012 02:31: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> <50BCF9AD.7030309@siva.com.mk> <194934E0-13F3-43AF-97F0-C62EFDAA0B37@linear.com> To: Ilija Kocho X-AnalysisOut: [v=2.0 cv=Vt6U9ZKn 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=YB6z0Vxgd9yQ6J8dT_8A:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10 a=xLpt9-x9cSEA:10 a=4KOvdA9js9DhV8CZ:21 a=MZFPf9i] X-AnalysisOut: [Sjd6YaG5B: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/msg00014.txt.bz2 IIija, Just to be clear, I created a new RedBoot project, imported your file, then= changed the IP to a fixed IP. Then I ran my application just as I document= ed in the previous mail. Mike On Dec 3, 2012, at 7:18 PM, Michael Jones wrote: > IIija, >=20 > I used your version of the RedBoot project and got the same results. Perh= aps you can take a look at my application project and see if I have done so= mething wrong. If you have a hello world project that works, I could run it= and see if it works here. >=20 > Mike >=20 >=20 >=20 >=20 > On Dec 3, 2012, at 12:12 PM, Ilija Kocho wrote: >=20 >> 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 SIGT= RAPs. So I am stuck, but at least I have Insight/gdb running and can see wh= at the code is doing. But, I don't know enough about the memory usage to kn= ow 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. = Same 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 s= ays: >>>=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 = pointing to reset_vector, or something else causes the SIGTRAP, leading bac= k here. >>>=20 >>> At this point I have to admit ignorance of how traps work. But moving f= orward, I did a step next line in the debugger. This resulted in an infinit= e 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 instruct= ion was hit, and then GDB should handle the breakpoint. >>>=20 >>> My interpretation of the GDB console is that the target trapped at vect= ors.S:101, but I used the debugger to put a break point at the first instru= ction in main. I suppose it is possible this is where it thinks the trap go= es... >>>=20 >>> but I am guessing something is in the wrong place, like loading the pro= gram 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 worl= d app on a K60 Tower Board. >>>>>=20 >>>>> I have RedBoot running from ROM and I can ping the ethernet port, so = presumably 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 obvio= us way to run and debug. >>>>>=20 >>>>> PROBLEM >>>>> -------------- >>>>>=20 >>>>> I am getting a conflict I don't know how to resolve. I have set CYG_H= AL_STARTUP_VAR =3D SRAM. This results in CYG_HAL_STARTUP =3D SRAM by calcul= ation. >>>>>=20 >>>>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_H= AL_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 = 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 wi= th >>>> 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/ec= os >>>> 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 >=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 >=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