[ECOS]Debugger fails when I add kernel support

Sergei Gavrikov sergei.gavrikov@gmail.com
Tue Apr 7 18:34:00 GMT 2009


On Tue, Apr 07, 2009 at 07:05:29PM +0300, Sergei Gavrikov wrote:
> On Tue, Apr 07, 2009 at 04:40:42PM +0200, Robert Brusa wrote:
> > 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
> 
> I'm sure that is not "arm_gnu" related, something is wrong witch eCos
> configuration. Forget about own application. You have to make work two
> famous eCos examples for your target: these are `twotreads' and `serial'
> (see $ECOS_REPOSITORY/../examples). Twothreads is exactly that what you
> need. First, it's hardy help using a `configtool' way. I'm sorry. BUT, I
> will try. What's your target's name exactly?  (It seems I missed the
> name). As I could understand you use ROM startup and the target has at
> the least two serial ports.
> 
> $ ecosconfig new <target> default
> 
> At least, you have to set the below options to get non-blocking serial
> I/O.
> 
> cdl_component CYGPKG_IO_SERIAL_DEVICES {
>     user_value 1
> };
> 
> cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
>     user_value 1
> };
> 
> Put the above in serial.ecm and import this file then.
> 
> $ ecosconfig import serial.ecm
> 
> About printf() channel...
> 
> $ less -p 'DEFAULT_CONSOLE \{' ecos.ecc
> 
> cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE sets a device name which
> will be used for printf(). Set it properly (edit ecos.ecc).
> 
> $ ecosconfig resolve && ecosconfig tree && make -s
> 
> cp -a $ECOS_REPOSITORY/../examples .
> 
> make -C examples INSTALL_DIR=`pwd`/install twothreads 
> make -C examples INSTALL_DIR=`pwd`/install serial 
> 
> There will be your test stuff under examples directory. Make twothreads
> works with JTAG.
> 
> Note: I do not know about your target, if your default startup RAM, it's
> possible you have to import and the below before to build eCos examples
> 
> cdl_component CYG_HAL_STARTUP {
>     user_value ROM
> };
> 
> Robert, only if you will manage `twothreads' then you will manage own
> application. 

Yet another 2 cents. Usually if I've got an issue I import the below too

cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
cdl_option CYGDBG_USE_TRACING {user_value 1};
cdl_option CYGDBG_IO_INIT {user_value 1};

and I fix CYGBLD_GLOBAL_CFLAGS:

    s/ -O2// 

to turn off any optimization if I use GDB. After every tweak of ecos.ecc
be sure that you rebuild eCos from scratch.


Sergei

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