Re: [ECOS] Kinetis TWR-K60N512-KIT questions

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

On 11.05.2011 10:47, jjp jjp wrote:
> Hi,
> Modifications in CDL file is in attach patch file (hal_kinetis.diff).
It seem versions to be reversed in your diff, but I could deduce you
have simply renamed "SRAM" to "RAM" in CDL. This won't work because RAM
startup is a different type of startup. It is intended to start from
RedBoot so it does not initialize exception vectors - which would
explain your hangups. SRAM start-up, on the other hand, is intended to
run (almost) alone, with little help of JTAG loader.

Please note that RAM startup is not yet implemented in the current
Kinetis port, my idea is to add it once (a board with) external RAM is
available. See STM32 port for details on RAM startup.

Have you tried your code with SRAM startup?

Regards
Ilija.

> I send you too a diff between my ecc file and default template (ecos_dflt_sram.diff) without SRAM modifications.
> You can test it with your hello world example.
> I don't need exception explanation until SRAM hello world example works properly.
> Code hangs in hal_reset_vsr (line 187), exactly in SVC routine hal_switch_state_vsr (line 141).
> Regards.
> ----------------------------------------
>> Date: Fri, 6 May 2011 09:35:47 +0200
>> From: ilijak@siva.com.mk
>> To: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] Kinetis TWR-K60N512-KIT questions
>>
>> On 05.05.2011 16:30, jjp jjp wrote:
>>> Hi,
>>> I test unified RAM configuration and it works for me with some modifications.
>>> -. Replace SRAM by RAM hal_cortexm_kinetis_twr_k60n512.cdl to disable execution of SWI in
>> Might help if I see your modified CDL (or diff). Have you tried with
>> original files?
>>
>>> hal_reset_vsr (line 187). Execution of this part reset tower and flash code runs again.
>> Other than selecting SRAM what is your configuration? Can you send me
>> the .ecc ?
>> What gnutools are you using?
>>
>>> -. Lookup /dev/ser3 and make cyg_io_write instead of printf. Code with printf reset tower and
>>> flash code runs again.
>>>
>>> I also try to use cortexm exception support but it fails.
>>> I install an exception handler with cyg_exception_set_handler for CYGNUM_HAL_VECTOR_SERVICE
>>> (vector 11 -> SVCall). I make a SWI call an I expect it to modify execution flow to call my exception handler.
>>> SWI calls hal_default_svc_vsr and R3 get a dummy value not a function address value.
>> I would need more information. Can you send some code snippet?
>>
>>> Why software interrupt doesn't call hal_default_exception_vsr?
>>> Regards.
>>>
>>> ----------------------------------------
>>>> Date: Thu, 5 May 2011 00:36:00 +0200
>>>> From: ilijak@siva.com.mk
>>>> To: ecos-discuss@ecos.sourceware.org
>>>> Subject: Re: [ECOS] Kinetis TWR-K60N512-KIT questions
>>>>
>>>> On 04.05.2011 12:46, jjp jjp wrote:
>>>>> Hi,
>>>>> It works with ecos toolchain and gcc-4.6 with -mcpu=cortex-m4!
>>>>> Great job Ilija.
>>>> Thanks for good words.
>>>> I am testing some integer DFT code with gcc-4.6 / Cortex-M4. Shows
>>>> performance improvement over M3 code even for plain C code.
>>>>
>>>>> My miktake was to put optimization flag to -O0 in global flags.
>>>>> I will test your RAM configuration and give you feedbacks.
>>>> I appreciate.
>>>>
>>>> Regards
>>>> Ilija
>>>>
>>>>
>>>> --
>>>> 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