[ECOS]Debugger fails when I add kernel support

Robert Brusa bob.brusa@gmail.com
Tue Apr 7 16:05:00 GMT 2009


On Tue, 07 Apr 2009 16:01:35 +0200, Sergei Gavrikov  
<sergei.gavrikov@gmail.com> wrote:

> On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
>> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov
>> <sergei.gavrikov@gmail.com> wrote:
>>
>> ..<cut>
>> >>Robert, of course, the right way is to define own macro (= CDL rule)  
>> in
>> >>the plf's stuff. But, that's not possible without a tweaking plf's  
>> code.
>> >>I thought about a froud hack: to add something like the below in  
>> CFLAGS
>> >>
>> >>    -D"HAL_IDLE_THREAD_ACTION(x)={}"
>> >>
>> >>Well, it's ugly, but, if you do not want to mess up 3.0 sources, it
>> >>would
>> >>be a way.
>> >>
>> >>Perhaps, eCos veterans know about another way.
>> >>
>> >
>> >It's just for reference how it was done for lpc2xxx variants:
>> >packages/hal/arm/lpc2xxx/var/current/include/var_arch.h:63
>> >
>> >So, I can use
>> >
>> >cdl_option CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE {
>> >    user_value 0
>> >};
>> >
>> >for my target to disable that "odd" mode. Certainly it can be disabled
>> >with `configtool' too.
>> >
>> >Sergei
>>
>> Sergei, I did it with brutal force: I modified the lines inside  
>> var_arch.h
>> in directory ecos/packages/hal/arm/at91/var/current/include such that  
>> the
>> macro
>> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I  
>> created a
>> new ecos and linked my little project with this new ecos. The results  
>> are
>> mixed:
>> a) As before, when switching power on with no JTAG debugger (BDI2000)
>> connected, the program launches and works fine.
>>
>> b) With the JTAG debugger connected, I am no longer in a position to
>> launch it with the BDI go 0 command (via telnet). No output at all.
>
> IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
> that your early startup has a loop in assembler during a few time to
> give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
> your hal_platform_startup.s (before any initialization, it should be
> just a loop in asm).

==> The BDI is configured to stop the target when it comes out of reset.  
And that it does wunderfully. I then click the run button and that's were  
the problems start :-(
>
>> c) I can set breakpoints in cyg_user_start and the output of the
>> diag_printf statement in this routine appear - but
>>    the output of the diag_printf routines in the thread created and
>> resumed from this reoutine do not appear - although I can catch
>>    breakpoints in this thread.
>>
>> Not a very clear situation. Do you have a good idea? Thanks and regards
>>    Robert
>
> diag_printf() is good for asserts, diagnostic output, etc., i.e. for
> debugging only. What is a reason to use it inside the threads?
>
> every plf. diagnostic "putc" is something like this blocking loop:
>
> 	do {
> 	    // check UART status
> 	} while (!can_send);
>
>
> It's not good for multi-threads applications. It blocks eCos, so, use
> printf() inside the threads, interrupt-driven and non-blocking serial
> I/O. Use a mutex to share printf() between the threads. I do not think
> that eCos's the floating-points-less printf() is heavy stuff. Robert,
> that is just my thoughts about your implementation. This is not JTAG
> related things.
>
>
> Sergei

Hi Sergei

Well, I used to have printf-statements in all my programs. But since  
working with the new arm-eabi toolchain, I found that all my programs  
crash in this printf statement. I reported this in the arm_gnu forum, but  
got no useful answer. :-(

Right now I have kicked out all diag_printf statements in the thread and  
put printf instead - No output in no case.
Then I changed it to fprintf(... and already the statement

fuser = fopen("/dev/ser1", "w");

comes back with fuser == 0 - even so I enabled ser0 and ser1 - the  
interrupt driven version at91serial - in configtool ...

Something very basic must be wrong in my case. If only I knew what??????  
:-(
   Robert



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



More information about the Ecos-discuss mailing list