From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8020 invoked by alias); 23 Dec 2012 17:58:42 -0000 Received: (qmail 8010 invoked by uid 22791); 23 Dec 2012 17:58:41 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,KHOP_DNSBL_BUMP,KHOP_THREADED,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,URIBL_RHS_DOB X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 Dec 2012 17:58:10 +0000 Received: from [77.28.162.83] (port=40527 helo=[192.168.178.36]) by tirion.supremecenter202.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TmpoO-0006Xs-MD; Sun, 23 Dec 2012 17:58:09 +0000 Message-ID: <50D7462D.1060707@siva.com.mk> Date: Sun, 23 Dec 2012 17:58:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Jones CC: eCos Discussion References: <50D2CCFE.4030800@dallaway.org.uk> <50D32FEE.8070309@dallaway.org.uk> <50D592C0.8090806@siva.com.mk> <02A08039-66E9-4427-9E68-7C66E5C4200D@linear.com> <50D5E4B9.5010300@siva.com.mk> <48C70F8E-290F-4E62-98FC-E5CEA9906AAE@linear.com> <50D64BA3.5030302@siva.com.mk> <88C69C62-38CD-4FDA-AED1-0126A8BEB66B@linear.com> In-Reply-To: <88C69C62-38CD-4FDA-AED1-0126A8BEB66B@linear.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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] Eclipse / CDT without Makefile Project X-SW-Source: 2012-12/txt/msg00051.txt.bz2 On 23.12.2012 01:19, Michael Jones wrote: > Ilija, > > What I am doing with MQX is debugging from Flash. If I use a PEMicro JTAG debugger, it is pretty fast to load 128K. My app does not use a lot of memory, so I have not run out of RAM. > > If I finally get a JTAG debugger, can I do the same with eCos? That is, debug from Flash? Sure. ROM startup builds Flash image. I would expect any JTAG interface supporting Kinetis flashing and providing GDB server to do the job. Ilija > > Mike > > On Dec 22, 2012, at 5:09 PM, Ilija Kocho wrote: > >> Hi Mike >> >> My insight in Eclipse is limited so I hope somebody else will hint us >> how to get the console I/O. >> >> Regarding the target issues, see my comment below. Here I will only say >> that for with respect to Redboot this is a small memory system and the >> application size is limited. That is the reason why I didn't provide RAM >> startup for systems without external memory. >> >> Ilija >> >> On 23.12.2012 00:08, Michael Jones wrote: >>> I noticed a few things, and did not copy the list because it might be Kinetis specific. See compilation problems towards the end. >>> >>> I setup a program like this: >>> >>> int integer1, integer2, sum; >>> >>> printf("Hello Mike.\n"); >>> >>> printf("Enter first integer:\n"); >>> scanf("%d", &integer1); >>> return 0; >>> >>> And when run, in the Eclipse gdb console (I finally realized there is more than one console): >>> >>> 947,145 (gdb) >>> 947,415 *running,thread-id="all" >>> 947,457 @"Hello Mike.\n" >>> 947,460 @"Enter first integer:\n" >>> >>> Suggests it got some printf data, but it did not appear on the app console. >>> >>> Then on the app console, I type 45 and on the gdb console get: >>> >>> 192,289 27-interpreter-exec console 45 >>> >>> I don't know if this means gdb sent 45 to RedBoot or not. I assume so. But the application did not respond. So tty problems are in both directions. I can't tell what is gdb and what is RedBoot. >>> >>> I extend the program like this: >>> >>> int integer1, integer2, sum; >>> >>> printf("Hello Mike.\n"); >>> >>> printf("Enter first integer:\n"); >>> scanf("%d", &integer1); >>> printf("Enter second integer:\n"); >>> scanf("%d", &integer2); >>> sum = integer1 + integer2; >>> >>> And I run from command line gdb (not Eclipse) which does print the one line Hello Mike app. I get: >>> >>> (gdb) cont >>> Continuing. >>> FLASH configuration checksum error or invalid key >>> ASSERT FAIL: <2>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream! >>> ASSERT FAIL: <2>stream.cxx [ 603] virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream! >>> >>> So things are not so well with the command line gdb either. >>> >>> I then tried another experiment with a program like this: >>> >>> int integer1, integer2, sum; >>> >>> printf("Hello Mike.\n"); >>> >>> printf("Enter first integer:\n"); >>> scanf("%d", &integer1); >>> printf("Enter second integer:\n"); >>> scanf("%d", &integer2); >>> sum = integer1 + integer2; >>> printf("Sum is %d\n", sum); >>> return 0; >>> >>> And I get a compile error: >>> >>> Description Resource Path Location Type >>> address 0x200106fc of hello_world section `.bss' is not within region `ram' hello_world C/C++ Problem >>> address 0x20010704 of hello_world section `.bss' is not within region `ram' hello_world C/C++ Problem >>> >>> So something is also not right with the compilation either. >> Compilation is probably OK, but linker complains because there is not >> enough memory. >> This makes me to suspect that previous errors are due to low memory, >> probably some stack overflow. >> >> The linker will include only used functions so if you scanf() it will >> add couple of tens KB to the image. You can save some memory if you >> configure printf()/scanf() without floating point support >> >>> Now, I backed off to just printf programs with multiple lines to see what can be done. >>> >>> A 10 line printf compiles and runs. >>> A 10 count for loop with printf works. >>> >>> So it does not appear that the number of lines in the program matters. >>> >>> I change the sum program to only printf and it can add numbers and print (gdb command line, not Eclipse) >>> >>> With some playing around, the scanf seems to cause the compiler error about regions. >>> >>> So I think try: >>> >>> c = getchar(); >>> >>> And with the command line gdb it prints, then hangs, and typing a character does not let the program proceed. So this seems like even with the command line arm-eabi-gdb, console input may not be routed back through RedBoot to the application. >>> >>> With the example redboot and application projects you sent, are you able to read from stdin? >>> >>> Do you know how to get Eclipse to handle IO for gdb? >> I have the same problem with Eclipse. >> But I usually activate the (real) serial device driver and I get I/O on >> serial port. >> >> >> -- >> 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