Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones <mjones at linear dot com>]

IIija,

I would love to just use Eclipse, and have the Config tool generate a compatible tree. Then use a standard debugger interface, like the PEMicro tools. The experience using Code Warrior with MQX is overall good. The thing I don't like about MQX is having to configure things with #define in include files. I really like that eCos takes the configuration out of the code tree. This makes it much easier to have multiple configurations, especially when using source code control.

I suppose I could just take the configuration results and use Code Warrior, but I loose some generality if my end users want to compile and debug on other targets.

Do you have any suggestions on a generic compile and debugging tool chain that includes a JTAG debugger and has a low entry price? I would guess that eCos could be integrated into Eclipse, but the issue would be supporting debug on all the different targets.

Mike




On Dec 2, 2012, at 9:52 AM, Ilija Kocho <ilijak@siva.com.mk> wrote:

> Jones,
> 
> On 02.12.2012 16:44, Michael Jones wrote:
>> IIija,
>> 
>> In my case, I already have an application in MQX, and it fits in a K60N512 with room to spare. There is a lot of value in applications that have minimum component count, and minimum cost. My goal is to port the application to eCos so that I de-constrain the target choice. 
> 
> FAOD, my comment is about debugging with RedBoot not eCos. For
> standalone eCos application 128KiB RAM is plenty (dependent of
> application of course). RedBoot provides some debugging facility but it
> will occupy some memory for it's own use so less memory for application.
> Therefore, provided that you have some kind of JTAG debugger you do not
> need RedBoot, unless you need dynamic firmware loading. In that case
> something like FLASH startup (mentioned in my previous mail) may be a
> solution.
> 
>> The eCos architecture is similar enough to MQX to make the port practical. For this application to work, I will have to add support for I2C,
> 
> Actually there is already I2C driver for eCos, almost ready for check
> in. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397
> I would ask Tomas, if he receives this mail, to tell us about the status
> of the driver.
> 
>> create a disk from part of the FLASH (MQX can do this through the BSP and Posix calls), use an SD card, use serial, and ethernet.
> SD card works over SPI but there are 2 issues:
> 
> 1. If you are using revision1 silicon you need to swap MISO and MOSI.
> (Revision2 as well as K70 have additional PIN multiplexing that fixes this.
> 2. There is a small bug in SPI driver that I discovered recently that
> didn't show on our custom hardware but. I am preparing a fix.
> 
>> The real constraints on the application are fast handling of interrupts and accurate timers triggering small amounts of time sensitive IO tasks. Memory is not such an issue.
>> 
>> Once I get a hello world working that does not depend on external memory, I'll post a bug and my results, etc.
>> 
>> 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
>> 
> 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss