From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32494 invoked by alias); 3 Dec 2012 19:13:02 -0000 Received: (qmail 32477 invoked by uid 22791); 3 Dec 2012 19:13:01 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED 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; Mon, 03 Dec 2012 19:12:52 +0000 Received: from c-5b1ce155.46-4-64736c11.cust.bredbandsbolaget.se ([85.225.28.91]:50471 helo=[192.168.0.110]) by tirion.supremecenter202.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TfbRh-0006zf-QA; Mon, 03 Dec 2012 19:12:50 +0000 Message-ID: <50BCF9AD.7030309@siva.com.mk> Date: Mon, 03 Dec 2012 19:13: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: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020101090606070304060702" 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/msg00012.txt.bz2 --------------020101090606070304060702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 6739 Mike I need insight in your RedBoot configuration. It would help if you send me the ECM file (File->Export...) 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. FYI you can also initialize RedBoot configuration (fconfig -i) so you won't need to enter tftp host every time. I hope this will work for you. Ilija On 03.12.2012 01:01, Michael Jones wrote: > 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 the code is doing. But, I don't know enough about the memory usage to know what 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 //========================================================================== > 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 > 94 .align 2 > 95 .global reset_vector > 96 .thumb > 97 .thumb_func > 98 .type reset_vector, %function > 99 reset_vector: > 100 > - 101 ldr sp,=hal_startup_stack > - 102 b hal_reset_vsr > 103 > 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 pointing to reset_vector, or something else causes the SIGTRAP, leading back here. > > At this point I have to admit ignorance of how traps work. But moving forward, 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. > > 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 instruction 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 >> >> On 01.12.2012 22:07, Michael Jones wrote: >>> BACKGROUND >>> ---------------------- >>> >>> I am having a little bit of trouble trying to get my first hello world app on a K60 Tower Board. >>> >>> I have RedBoot running from ROM and I can ping the ethernet port, so presumably I will eventually get GDB to talk to it. >>> >>> 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 obvious way to run and debug. >>> >>> PROBLEM >>> -------------- >>> >>> I am getting a conflict I don't know how to resolve. I have set CYG_HAL_STARTUP_VAR = SRAM. This results in CYG_HAL_STARTUP = SRAM by calculation. >>> >>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HAL_STARTUP == 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... >> >> SRAM startup is kind of "stand-alone" in a way it does not depend on >> RedBoot (but depends on JTAG debugger) >> >>> QUESTIONS >>> ----------------- >>> >>> 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. >> >> 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? >> >>> 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=1001623 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 :) >> >> I hope this helps and I would appreciate feedback. >> >> Regards >> Ilija >> -- >> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > --------------020101090606070304060702 Content-Type: text/plain; charset=UTF-8; name="rb_k60.ecm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rb_k60.ecm" Content-length: 1136 cdl_savefile_version 1; cdl_savefile_command cdl_savefile_version {}; cdl_savefile_command cdl_savefile_command {}; cdl_savefile_command cdl_configuration { description hardware template package }; cdl_savefile_command cdl_package { value_source user_value wizard_value inferred_value }; cdl_savefile_command cdl_component { value_source user_value wizard_value inferred_value }; cdl_savefile_command cdl_option { value_source user_value wizard_value inferred_value }; cdl_savefile_command cdl_interface { value_source user_value wizard_value inferred_value }; cdl_configuration eCos { description "" ; package CYGPKG_IO_FLASH current ; package CYGPKG_IO_ETH_DRIVERS current ; }; cdl_option CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE { user_value 4096 }; #cdl_option CYGBLD_REDBOOT_LOAD_INTO_FLASH { # user_value 1 #}; cdl_option CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK { user_value -1 }; #cdl_option CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_COUNT { # user_value 8 #}; cdl_option CYGSEM_REDBOOT_FLASH_COMBINED_FIS_AND_CONFIG { user_value 0 }; cdl_option CYGNUM_REDBOOT_FLASH_CONFIG_BLOCK { user_value -3 }; --------------020101090606070304060702 Content-Type: text/plain; charset=us-ascii Content-length: 148 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss --------------020101090606070304060702--