[ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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

QUESTIONS
-----------------

1) Can I ignore this conflict and get the monitor and app to work?

2) Is there a better approach?

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?

Thanks,

Mike

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

I have a little more info on this...

I ignored the conflict and with some pain finally got an SREC file built and ready to load.

I failed to get kermit and ymodem to work. If anyone knows a way of loading with ymodem from linux using telnet or similar application over IP, I could use a recipe. TFTP is hard to make work with VMs when you have ethernet and wireless.

I finally was able to load via TFTP, and I get an error from the loader saying the address was not a valid address. The image tries to load at 0x1FFF 0400. This seems to be the address in the image.

Using version, the valid range starts at 0x1FFF CC70. So I load specifically to that address and use "go" with the specified entry point of 0x1FFF CC89.

The result: no output from printf.

telnet 192.168.0.10 9000
RedBoot> load -v -h 192.168.0.2 -b 0x1fffcc70 hello.srec
Address offset = 0xffffc890
Entry point: 0x1fffcc89, address range: 0x1fffcc79-0x20007bec
RedBoot> go 0x1fffcc89

The app is nothing more than:

#include <stdio.h>

int main(void)
{
 printf("Hello, eCos world!\n");
 return 0;
}


I still have the same original questions about SRAM vs RAM and the conflict I ignored. I have no idea if the image will work with this conflict.

Now I have more questions:

1) Why is the range of valid addresses in RedBoot different than the starting address in the image? Is RedBoot using some RAM? Am I supposed to manually set the start address to a safe place?
2) Is it valid to load at a different address and use the new entry point as I showed above? Meaning, is the image relocatable?
3) Should the printf have printed on the RedBoot console?
4) What is the effect of the return 0 on the RedBoot prompt? Should it release control so you can type?


Mike


On Dec 1, 2012, at 2:07 PM, Michael Jones <mjones@linear.com> 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
> 
> QUESTIONS
> -----------------
> 
> 1) Can I ignore this conflict and get the monitor and app to work?
> 
> 2) Is there a better approach?
> 
> 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?
> 
> Thanks,
> 
> Mike
> 
> --
> 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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

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

[-- Attachment #2: kinetis_var_ram-startup_cdl_121202.diff --]
[-- Type: text/x-patch, Size: 1331 bytes --]

diff -ruN -x CVS -x '.*' ecos/packages/hal/cortexm/kinetis/var/current/cdl/hal_cortexm_kinetis.cdl ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/cdl/hal_cortexm_kinetis.cdl
--- ecos/packages/hal/cortexm/kinetis/var/current/cdl/hal_cortexm_kinetis.cdl	2012-11-03 17:13:05.953836177 +0100
+++ ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/cdl/hal_cortexm_kinetis.cdl	2012-12-01 22:37:50.159462935 +0100
@@ -209,7 +209,7 @@
         parent        CYG_HAL_STARTUP_ENV
         default_value { (CYG_HAL_STARTUP_PLF) && (CYG_HAL_STARTUP_PLF!="ByVariant") ?
                         "ByPlatform" : "ROM" }
-        legal_values  { "ROM" "SRAM" }
+        legal_values  { "ROM" "SRAM" "RAM" }
         active_if     ((!CYG_HAL_STARTUP_PLF) || (CYG_HAL_STARTUP_PLF=="ByVariant"))
         description   "
             'ROM' startup builds a stand-alone application which will
@@ -340,6 +340,8 @@
             . CYGHWR_HAL_CORTEXM_KINETIS_OC_MEM_LAYOUT  . "_rom" :
             (CYG_HAL_STARTUP == "SRAM") ? "kinetis_"
             . CYGHWR_HAL_CORTEXM_KINETIS_OC_MEM_LAYOUT  . "_sram" :
+            (CYG_HAL_STARTUP == "RAM") ? "kinetis_"
+            . CYGHWR_HAL_CORTEXM_KINETIS_OC_MEM_LAYOUT  . "_ram" :
             "undefined" }
         description "
             Combination of 'Startup type' and 'Kinetis part'

[-- Attachment #3: kinetis_var_ram-startup_mlt_121202.diff --]
[-- Type: text/x-patch, Size: 2985 bytes --]

diff -ruN -x CVS -x '.*' ecos/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.h ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.h
--- ecos/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.h	1970-01-01 01:00:00.000000000 +0100
+++ ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.h	2012-12-01 22:39:30.267467079 +0100
@@ -0,0 +1,18 @@
+// eCos memory layout
+
+#ifndef __ASSEMBLER__
+#include <cyg/infra/cyg_type.h>
+#include <stddef.h>
+
+#endif
+#define CYGMEM_REGION_ram (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE)
+#define CYGMEM_REGION_ram_SIZE (CYGHWR_HAL_KINETIS_SRAM_SIZE-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE)
+#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
+
+#ifndef __ASSEMBLER__
+extern char CYG_LABEL_NAME (__heap1) [];
+#endif
+#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
+#define CYGMEM_SECTION_heap1_SIZE (CYGMEM_REGION_ram+CYGMEM_REGION_ram_SIZE - (size_t) CYG_LABEL_NAME (__heap1))
+
+
diff -ruN -x CVS -x '.*' ecos/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.ldi ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.ldi
--- ecos/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.ldi	1970-01-01 01:00:00.000000000 +0100
+++ ecos_kin_jones/packages/hal/cortexm/kinetis/var/current/include/pkgconf/mlt_kinetis_flash_unisram_ram.ldi	2012-12-02 10:23:47.950382495 +0100
@@ -0,0 +1,34 @@
+// eCos memory layout
+
+#include <pkgconf/hal.h>
+#include <cyg/infra/cyg_type.inc>
+
+MEMORY
+{
+    ram  : ORIGIN = 0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE, LENGTH = CYGHWR_HAL_KINETIS_SRAM_SIZE-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
+    flash : ORIGIN = 0x00000000, LENGTH = CYGHWR_HAL_KINETIS_FLASH_SIZE
+}
+
+SECTIONS
+{
+    SECTIONS_BEGIN
+    SECTION_rom_vectors (ram, 0x20000400 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE + 0xe000, LMA_EQ_VMA)
+    SECTION_RELOCS (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_text (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_fini (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_rodata (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_fixup (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_gcc_except_table (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_eh_frame (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_got (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_sram (ram, ALIGN (0x8), LMA_EQ_VMA)
+    SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
+    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
+    SECTIONS_END
+}
+
+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;


[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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. 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, 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.

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

On 02.12.2012 18:53, Michael Jones wrote:
> 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.

Regarding commercial tools, I don't know if there is a bundled JTAG
debugger with eCos development tools, but I can imagine that it's easy
to combine any JTAG debugger supporting GDB server with CodeConfidence
Eclipse based IDE. You only need to check which ones can flash Kinetis.

In our company we use Ronetix PEEDI with plain Eclipse.

Ilija

>
> 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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

On 02.12.2012 18:53, Michael Jones wrote:
> 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.
If you like scripting, also give a try to ecosconfig, great help for
repetitive jobs.

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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 <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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

[-- Attachment #1: Type: text/plain, Size: 6739 bytes --]

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 <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
>


[-- Attachment #2: rb_k60.ecm --]
[-- Type: text/plain, Size: 1136 bytes --]

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
};


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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 <ilijak@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 <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
>> 
> 
> <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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

IIija,

Just to be clear, I created a new RedBoot project, imported your file, then changed the IP to a fixed IP. Then I ran my application just as I documented in the previous mail.

Mike


On Dec 3, 2012, at 7:18 PM, Michael Jones <mjones@linear.com> wrote:

> 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 <ilijak@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 <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
>>> 
>> 
>> <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
> 


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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Michael Jones]

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?

- 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?

- 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 :-)

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

Does the RAM setup need to have these changed?
    
Mike




On Dec 3, 2012, at 12:12 PM, Ilija Kocho <ilijak@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 <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
>> 
> 
> <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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

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).

>     
> Mike
>
>
>
>
> On Dec 3, 2012, at 12:12 PM, Ilija Kocho <ilijak@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 <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
>> <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

Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict

[Ilija Kocho]

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 <ilijak@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 <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
>>> <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