Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones <mjones at linear dot com>]

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


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss