Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho <ilijak@siva.com.mk>]

[-- Attachment #1: Type: text/plain, Size: 6739 bytes --]

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
>


[-- Attachment #2: rb_k60.ecm --]
[-- Type: text/plain, Size: 1136 bytes --]

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
};


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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