Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones <mjones at linear dot com>]

IIija,

I used your version of the RedBoot project and got the same results. Perhaps you can take a look at my application project and see if I have done something wrong. If you have a hello world project that works, I could run it and see if it works here.

Mike




On Dec 3, 2012, at 12:12 PM, Ilija Kocho <ilijak@siva.com.mk> wrote:

> 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 <ilijak@siva.com.mk> 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
>>> <kinetis_var_ram-startup_cdl_121202.diff><kinetis_var_ram-startup_mlt_121202.diff>-- 
>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>> 
> 
> <rb_k60.ecm>-- 
> 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