[ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict
Michael Jones
mjones@linear.com
Tue Dec 4 02:31:00 GMT 2012
IIija,
Just to be clear, I created a new RedBoot project, imported your file, then changed the IP to a fixed IP. Then I ran my application just as I documented in the previous mail.
Mike
On Dec 3, 2012, at 7:18 PM, Michael Jones <mjones@linear.com> wrote:
> 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
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list