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
>
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
};
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
