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