On 04.12.2012 09:42, Ilija Kocho wrote:
> On 04.12.2012 06:32, Michael Jones wrote:
>> IIija,
>>
>> I have some questions:
>>
>> - Is the Kinetis rev 1/2 silicon rev or Tower rev? I have part number
>> PK60n512vmd100. Best I can tell the silicon rev is 1, because there is no
>> number between 512 and V. The Tower board is Rev A. Can you disambiguate
>> things for me?
> It's silicon revision, ref:
> http://cache.freescale.com/files/32bit/doc/app_note/AN4445.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
>
>> - If I turn off unified Ram, the configuration does not build. Any idea why?
>> I verified this by deleting the build and install dirs, the building.
>> Nothing is creating. I was attempting to see if it fixed the problem. Is
>> there a log somewhere to look at for clues?
> There's no linker script for non-unified SRAM in the (ad hoc) RAM
> startup patch.
>
>> - I would like to verify that you don't add the RedBoot package to the
>> application to work with the monitor. I assume that enabling Working with a
>> ROM monitor is all that is needed. Just being paranoid :-)
> Sure. And /Work with ROM monitor/ should enable by default when RAM
> startup is selected.
>
>> - On the virtual vector table that is shared by the Rom monitor and
>> applicaiton, I dug up the linker settings.
>>
>> The Rom Monitor has this:
>>
>> hal_vsr_table = (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE);
>> hal_virtual_vector_table = hal_vsr_table + 128*4;
>> hal_startup_stack = 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE;
>>
>> The application using RAM has this:
>>
>> hal_vsr_table = (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE);
>> hal_virtual_vector_table = hal_vsr_table + 128*4;
>> hal_startup_stack = 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE;
>>
>> I am not sure which of these are to be shared. I think the virtual vector
>> table are shared so that the monitor will work. I would think the startup
>> stack would not be shared. And the hal_vsr_table might be shared, but I am
>> not sure.
> You are right for both. However, effectively there isn't collision over
> VSR table because RAM startup (exclusively) omits VSR table
> initialization (arch/current/src/hal_misc.c).
>
>> Does the RAM setup need to have these changed?
> No need to change but /SECTION_rom_vectors/ base may need. In the patch
> it is 0xe000. Check the RedBoot memory report (printed during boot).
To precise, 0xe000 is not base but offset from RedBoot's base.
>
>>
>> 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
