Re: [ECOS] Eclipse / CDT without Makefile Project

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

On 23.12.2012 01:19, Michael Jones wrote:
> Ilija,
>
> What I am doing with MQX is debugging from Flash. If I use a PEMicro JTAG debugger, it is pretty fast to load 128K. My app does not use a lot of memory, so I have not run out of RAM.
>
> If I finally get a JTAG debugger, can I do the same with eCos? That is, debug from Flash?

Sure. ROM startup builds Flash image. I would expect any JTAG interface
supporting Kinetis flashing and providing GDB server to do the job.

Ilija

>
> Mike
>
> On Dec 22, 2012, at 5:09 PM, Ilija Kocho <ilijak@siva.com.mk> wrote:
>
>> Hi Mike
>>
>> My insight in Eclipse is limited so I hope somebody else will hint us
>> how to get the console I/O.
>>
>> Regarding the target issues, see my comment below. Here I will only say
>> that for with respect to Redboot this is a small memory system and the
>> application size is limited. That is the reason why I didn't provide RAM
>> startup for systems without external memory.
>>
>> Ilija
>>
>> On 23.12.2012 00:08, Michael Jones wrote:
>>> I noticed a few things, and did not copy the list because it might be Kinetis specific. See compilation problems towards the end.
>>>
>>> I setup a program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    return 0;
>>>
>>> And when run, in the Eclipse gdb console (I finally realized there is more than one console):
>>>
>>> 947,145 (gdb) 
>>> 947,415 *running,thread-id="all"
>>> 947,457 @"Hello Mike.\n"
>>> 947,460 @"Enter first integer:\n"
>>>
>>> Suggests it got some printf data, but it did not appear on the app console.
>>>
>>> Then on the app console, I type 45 and on the gdb console get:
>>>
>>> 192,289 27-interpreter-exec console 45
>>>
>>> I don't know if this means gdb sent 45 to RedBoot or not. I assume so. But the application did not respond. So tty problems are in both directions. I can't tell what is gdb and what is RedBoot.
>>>
>>> I extend the program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    printf("Enter second integer:\n");
>>>    scanf("%d", &integer2);
>>>    sum = integer1 + integer2;
>>>
>>> And I run from command line gdb (not Eclipse) which does print the one line Hello Mike app. I get:
>>>
>>> (gdb) cont
>>> Continuing.
>>> FLASH configuration checksum error or invalid key
>>> ASSERT FAIL: <2>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream!
>>> ASSERT FAIL: <2>stream.cxx          [ 603] virtual Cyg_ErrNo Cyg_StdioStream::write()                                                           Stream object is not a valid stream!
>>>
>>> So things are not so well with the command line gdb either.
>>>
>>> I then tried another experiment with a program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    printf("Enter second integer:\n");
>>>    scanf("%d", &integer2);
>>>    sum = integer1 + integer2;
>>>    printf("Sum is %d\n", sum);
>>>    return 0;
>>>
>>> And I get a compile error:
>>>
>>> Description	Resource	Path	Location	Type
>>> address 0x200106fc of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>>> address 0x20010704 of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>>>
>>> So something is also not right with the compilation either.
>> Compilation is probably OK, but linker complains because there is not
>> enough memory.
>> This makes me to suspect that previous errors are due to low memory,
>> probably some stack overflow.
>>
>> The linker will include only used functions so if you scanf() it will
>> add couple of tens KB to the image. You can save some memory if you
>> configure printf()/scanf() without floating point support
>>
>>> Now, I backed off to just printf programs with multiple lines to see what can be done.
>>>
>>> A 10 line printf compiles and runs.
>>> A 10 count for loop with printf works.
>>>
>>> So it does not appear that the number of lines in the program matters.
>>>
>>> I change the sum program to only printf and it can add numbers and print (gdb command line, not Eclipse)
>>>
>>> With some playing around, the scanf seems to cause the compiler error about regions.
>>>
>>> So I think try:
>>>
>>>   c = getchar();
>>>
>>> And with the command line gdb it prints, then hangs, and typing a character does not let the program proceed. So this seems like even with the command line arm-eabi-gdb, console input may not be routed back through RedBoot to the application.
>>>
>>> With the example redboot and application projects you sent, are you able to read from stdin?
>>>
>>> Do you know how to get Eclipse to handle IO for gdb?
>> I have the same problem with Eclipse.
>> But I usually activate the (real) serial device driver and I get I/O on
>> serial port.
>>
>>
>> -- 
>> 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