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 <ili...@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 <ili...@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
