[ECOS] RedBoot

[ECOS] RedBoot

[Anthony Massa]

I am able to open my mbx.img file and download it to the target.

I have found that Insight hangs in the function hal_if_init() in
\common\hal_if.c.

Could you help me out as to what may be causing this problem?

Thanks.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I am able to open my mbx.img file and download it to the target.
> 
> I have found that Insight hangs in the function hal_if_init() in
> \common\hal_if.c.
> 
> Could you help me out as to what may be causing this problem?

Are you single stepping through it? Does it work correctly if you step over
it?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] RedBoot

[Anthony Massa]

> > I am able to open my mbx.img file and download it to the target.
> >
> > I have found that Insight hangs in the function hal_if_init() in
> > \common\hal_if.c.
> >
> > Could you help me out as to what may be causing this problem?
>
> Are you single stepping through it? Does it work correctly if you
> step over
> it?
>


I initially single-stepped through the first for loop and the board hung.
Then I read the very detailed comment before which explicitly says not to do
this.  So I re-ran the application and stepped over it and it still hung the
board.  I tried to set a breakpoint at the next function call after
hal_if_init(), and the board still hangs before hitting the breakpoint.

Is there something I should look at or try?

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I initially single-stepped through the first for loop and the board hung.
> Then I read the very detailed comment before which explicitly says not to do
> this.  So I re-ran the application and stepped over it and it still hung the
> board.  I tried to set a breakpoint at the next function call after
> hal_if_init(), and the board still hangs before hitting the breakpoint.
> 
> Is there something I should look at or try?

Setting a breakpoint much further in the initialization, like cyg_start.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] RedBoot

[Anthony Massa]

I have rebuilt ecos using the default configuration for the MBX template.  I
rebuilt my application using the new ecos build.  I then downloaded the code
and set a breakpoint at cyg_start().  I am still seeing the board hang when
I run the code.  On the RedBoot serial port I get a $T... string GDB output
message.  I can hit return when I am on the terminal connected to the serial
port and I get the same $T string GDB message.  I'm really confused as to
why this is hanging.

RE: [ECOS] RedBoot

[Anthony Massa]

I found that I was having the same problems as the ones discussed in this
post:
http://sources.redhat.com/ml/ecos-discuss/2001-04/msg00006.html

After getting past that, I am now finding that my code loads over the
Ethernet port.  However, when I run my code it prints out the networking
information, such as "Network stack using..." then I get a message:

[New thread 1]

The board then seems to hang for a little while and then the program stops.
I have breakpoints at cyg_start and cyg_user_start, however, neither of
these get hit by the debugger.  The target disconnects from the debugger as
well.

Any help?

Thanks.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I found that I was having the same problems as the ones discussed in this
> post:
> http://sources.redhat.com/ml/ecos-discuss/2001-04/msg00006.html
> 
> After getting past that, I am now finding that my code loads over the
> Ethernet port.  However, when I run my code it prints out the networking
> information, such as "Network stack using..." then I get a message:
> 
> [New thread 1]
> 
> The board then seems to hang for a little while and then the program stops.
> I have breakpoints at cyg_start and cyg_user_start, however, neither of
> these get hit by the debugger.  The target disconnects from the debugger as
> well.

Well, this may indicate that it did hit the breakpoint, but has failed for
some other reason. Does it do the same thing when you don't set
breakpoints?

Also try enabling remote protocol debugging in GDB using "set remotedebug
1" (or in newer versions, "set debug remote 1"). 

Earlier you wrote:
> I have rebuilt ecos using the default configuration for the MBX template.  I
> rebuilt my application using the new ecos build.  I then downloaded the code
> and set a breakpoint at cyg_start().  I am still seeing the board hang when
> I run the code.  On the RedBoot serial port I get a $T... string GDB output
> message.  I can hit return when I am on the terminal connected to the serial
> port and I get the same $T string GDB message.  I'm really confused as to
> why this is hanging.

The $T string means that the target is reporting a signal and trying to
inform GDB - probably the breakpoint you hit. But if it's coming out the
serial port, whereas if GDB is connected over ethernet you won't see it.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RE:RedBoot

[Anthony Massa]

>Go into the TCP/IP configuration and enable
>CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.

This option is already enabled in my eCos application build.  However, I
don't see any of
this information printed out.


>Have you enabled any funny options in this area, such as
>CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE or
>CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS ?

I have also verified that these two options are disabled as well.

Are there any other VIRTUAL_VECTOR options that I should have disabled?


>Note: in the default configuration, it should work. Demonstrably so on
>other targets.

The problem is that in the default configuration, there isn't any networking
support.  I need to have the networking support enabled.  I have attached
the output to my .ecm file below.




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 "" ;
    hardware    mbx ;
    template    net ;
    package -hardware CYGPKG_HAL_POWERPC current ;
    package -hardware CYGPKG_HAL_POWERPC_MPC8xx current ;
    package -hardware CYGPKG_HAL_POWERPC_MBX current ;
    package -hardware CYGPKG_HAL_QUICC current ;
    package -hardware CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC current ;
    package -hardware CYGPKG_DEVS_ETH_POWERPC_QUICC current ;
    package -hardware CYGPKG_DEVS_FLASH_MBX current ;
    package -hardware CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current ;
    package CYGPKG_HAL current ;
    package CYGPKG_IO current ;
    package CYGPKG_IO_SERIAL current ;
    package CYGPKG_INFRA current ;
    package CYGPKG_ISOINFRA current ;
    package CYGPKG_KERNEL current ;
    package CYGPKG_MEMALLOC current ;
    package CYGPKG_LIBC current ;
    package CYGPKG_LIBC_TIME current ;
    package CYGPKG_LIBC_STDLIB current ;
    package CYGPKG_LIBC_STRING current ;
    package CYGPKG_LIBC_I18N current ;
    package CYGPKG_LIBC_SETJMP current ;
    package CYGPKG_LIBC_STARTUP current ;
    package CYGPKG_LIBC_STDIO current ;
    package CYGPKG_LIBM current ;
    package CYGPKG_POSIX current ;
    package CYGPKG_UITRON current ;
    package CYGPKG_IO_WATCHDOG current ;
    package -template CYGPKG_IO_WALLCLOCK current ;
    package -template CYGPKG_ERROR current ;
    package -template CYGPKG_IO_FILEIO current ;
    package -template CYGPKG_NET current ;
    package -template CYGPKG_IO_ETH_DRIVERS current ;
};

cdl_option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT {
    user_value 0
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
    user_value 0
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_ICTRL {
    user_value 1
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_RESET {
    user_value 1
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_DELAY_US {
    user_value 1
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_CACHE {
    user_value 1
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_DATA {
    user_value 1
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS {
    user_value 0
};

cdl_option CYGHWR_HAL_POWERPC_BOARD_SPEED {
    user_value 40
};

cdl_option CYGBLD_ISO_CTYPE_HEADER {
    inferred_value 1 <cyg/libc/i18n/ctype.inl>
};

cdl_option CYGBLD_ISO_ERRNO_CODES_HEADER {
    inferred_value 1 <cyg/error/codes.h>
};

cdl_option CYGBLD_ISO_ERRNO_HEADER {
    inferred_value 1 <cyg/error/errno.h>
};

cdl_option CYGBLD_ISO_STDIO_FILETYPES_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_STREAMS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEACCESS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_CHAR_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_DIRECT_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_ERROR_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDLIB_STRCONV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/atox.inl>
};

cdl_option CYGBLD_ISO_STDLIB_ABS_HEADER {
    inferred_value 1 <cyg/libc/stdlib/abs.inl>
};

cdl_option CYGBLD_ISO_STDLIB_DIV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/div.inl>
};

cdl_option CYGBLD_ISO_STRERROR_HEADER {
    inferred_value 1 <cyg/error/strerror.h>
};

cdl_option CYGBLD_ISO_STRTOK_R_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_MEMFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_STRFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_POSIX_TIMER_TYPES_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_C_TIME_TYPES_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_POSIX_TIMERS_HEADER {
    inferred_value 1 <cyg/posix/time.h>
};

cdl_option CYGBLD_ISO_C_CLOCK_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_SIGNAL_NUMBERS_HEADER {
    inferred_value 1 <cyg/posix/signal.h>
};

cdl_option CYGBLD_ISO_SIGNAL_IMPL_HEADER {
    inferred_value 1 <cyg/posix/signal.h>
};

cdl_option CYGBLD_ISO_SETJMP_HEADER {
    inferred_value 1 <cyg/libc/setjmp/setjmp.h>
};

cdl_option CYGBLD_ISO_SIGSETJMP_HEADER {
    inferred_value 1 <cyg/posix/sigsetjmp.h>
};

cdl_option CYGBLD_ISO_DIRENT_HEADER {
    inferred_value 1 <cyg/fileio/dirent.h>
};

cdl_option CYGBLD_ISO_PTHREADTYPES_HEADER {
    inferred_value 1 <cyg/posix/types.h>
};

cdl_option CYGBLD_ISO_BSDTYPES_HEADER {
    inferred_value 1 <sys/bsdtypes.h>
};

cdl_option CYGBLD_ISO_UTSNAME_HEADER {
    inferred_value 1 <cyg/posix/utsname.h>
};

cdl_option CYGBLD_ISO_SEMAPHORES_HEADER {
    inferred_value 1 <cyg/posix/semaphore.h>
};

cdl_option CYGBLD_ISO_PTHREAD_IMPL_HEADER {
    inferred_value 1 <cyg/posix/pthread.h>
};

cdl_option CYGBLD_ISO_POSIX_LIMITS_HEADER {
    inferred_value 1 <cyg/posix/limits.h>
};

cdl_option CYGBLD_ISO_OPEN_MAX_HEADER {
    inferred_value 1 <cyg/fileio/limits.h>
};

cdl_option CYGIMP_KERNEL_SCHED_SORTED_QUEUES {
    inferred_value 1
};

cdl_option CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE {
    inferred_value 1
};

cdl_component CYGSEM_KERNEL_SCHED_ASR_SUPPORT {
    inferred_value 1
};

cdl_option CYGSEM_KERNEL_SCHED_ASR_GLOBAL {
    inferred_value 1
};

cdl_option CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE {
    user_value 1638400
};

[ECOS] Re: RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> >Go into the TCP/IP configuration and enable
> >CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.
> 
> This option is already enabled in my eCos application build.  However, I
> don't see any of
> this information printed out.

That implies it's not getting an address. Thinking about it maybe you can't
have both RedBoot and the app getting an addr from DHCP. Perhaps give
RedBoot a static address to see.

Anyone else confirm?
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RE: RedBoot

[Anthony Massa]

> > >Go into the TCP/IP configuration and enable
> > >CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.
> >
> > This option is already enabled in my eCos application build.  However, I
> > don't see any of
> > this information printed out.
>
> That implies it's not getting an address. Thinking about it maybe
> you can't
> have both RedBoot and the app getting an addr from DHCP. Perhaps give
> RedBoot a static address to see.
>
> Anyone else confirm?


After reading a previous post from Hugo, I changed RedBoot to have a static
IP and gateway address.  The same thing happens when I do this.

Re: [ECOS] RE: RedBoot

[Hugo 'NOx' Tyson]

"Anthony Massa" <amassa@san.rr.com> writes:

> > > >Go into the TCP/IP configuration and enable
> > > >CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.
> > >
> > > This option is already enabled in my eCos application build.  However, I
> > > don't see any of
> > > this information printed out.
> >
> > That implies it's not getting an address. Thinking about it maybe
> > you can't
> > have both RedBoot and the app getting an addr from DHCP. Perhaps give
> > RedBoot a static address to see.
> >
> > Anyone else confirm?
> 
> After reading a previous post from Hugo, I changed RedBoot to have a static
> IP and gateway address.  The same thing happens when I do this.

Uh, you have called "init_all_network_interfaces()" in you app?  The
network doesn't initialize automatically - precisely to allow for the
flexibility we've been discussing.  I mean, the dhcp thread will manage
your leases *after the interfaces are brung up* but it won't initiate the
bringup.

I do advise staying with the static IP for RedBoot.

	- Huge

[ECOS] Re: RedBoot

[Anthony Massa]

>> >> I am running RedBoot on an MBX board and downloading my eCos
>> >application
>> >> with networking support.
>> >>
>> >> I noticed your post about the Ethernet device shutdown and
>> >was wondering if
>> >> I could possibly be running
>> >> into the same problem.
>> >
>> >Only if you don't have a DHCP server on your net and you're
>> >trying to use
>> >the ethernet driver for other purposes than the TCP/IP stack.
>> 
>> I have a DHCP server on my net.  However, my confusion comes 
>with the fact
>> that I have RedBoot coming up using BOOTP, which I have a 
>server for as
>> well.  So, RedBoot gets its IP address.  Is this address 
>then passed onto
>> the application, or is the application layer supposed to get 
>its own, new
>> address?
>> 
>> I'm a little confused about how the RedBoot and eCos app 
>layer stack coexist
>> on my target.  I am using the RedBoot Ethernet for debugging the
>> application.
>
>They each get their own addresses. Or one can be static and the other
>dynamic, or whatever you want. Think of them as completely separate.


Is there a message that is output when the DHCP client gets its address?

If so, my hang problem is occurring before the address is received by the
application.  It's odd that it outputs the debug string over the serial port
when the whole time it has been using the Remote/TCP connection for
debugging.

When I don't set breakpoints the same thing happens.

>Also try enabling remote protocol debugging in GDB using "set remotedebug
>1" (or in newer versions, "set debug remote 1"). 

Doesn't this get set when I use Insight, hit Run and a dialog comes up and I
set Remote/TCP with the IP address and port?  Do you mean to explicitly do
this after I open the application using the console?

--Anthony

[ECOS] Re: RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> >> >> I am running RedBoot on an MBX board and downloading my eCos
> >> >application
> >> >> with networking support.
> >> >>
> >> >> I noticed your post about the Ethernet device shutdown and
> >> >was wondering if
> >> >> I could possibly be running
> >> >> into the same problem.
> >> >
> >> >Only if you don't have a DHCP server on your net and you're
> >> >trying to use
> >> >the ethernet driver for other purposes than the TCP/IP stack.
> >>
> >> I have a DHCP server on my net.  However, my confusion comes
> >with the fact
> >> that I have RedBoot coming up using BOOTP, which I have a
> >server for as
> >> well.  So, RedBoot gets its IP address.  Is this address
> >then passed onto
> >> the application, or is the application layer supposed to get
> >its own, new
> >> address?
> >>
> >> I'm a little confused about how the RedBoot and eCos app
> >layer stack coexist
> >> on my target.  I am using the RedBoot Ethernet for debugging the
> >> application.
> >
> >They each get their own addresses. Or one can be static and the other
> >dynamic, or whatever you want. Think of them as completely separate.
> 
> Is there a message that is output when the DHCP client gets its address?

Go into the TCP/IP configuration and enable
CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.
 
> If so, my hang problem is occurring before the address is received by the
> application.  It's odd that it outputs the debug string over the serial port
> when the whole time it has been using the Remote/TCP connection for
> debugging.

Have you enabled any funny options in this area, such as
CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE or
CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS ?

If you export a minimal configuration file (Under File in the configuration
tool, or "ecosconfig export" on the command line) you can see what options
are non-default.

Note: in the default configuration, it should work. Demonstrably so on
other targets.

> When I don't set breakpoints the same thing happens.

Ah.
 
> >Also try enabling remote protocol debugging in GDB using "set remotedebug
> >1" (or in newer versions, "set debug remote 1").
> 
> Doesn't this get set when I use Insight, hit Run and a dialog comes up and I
> set Remote/TCP with the IP address and port?  Do you mean to explicitly do
> this after I open the application using the console?

I meant in the console. But it sounds like you definitely wouldn't receive
anything anyway if you are still seeing $T packets on the serial port.
You're right that you shouldn't see anything on the serial port. In which
case something in your application or your configuration is causing it to
get set to the serial port.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RE: RedBoot

[Anthony Massa]

> > > >Go into the TCP/IP configuration and enable
> > > >CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW, assuming it's eth0. Then rebuild.
> > >
> > > This option is already enabled in my eCos application build.  However,
I
> > > don't see any of
> > > this information printed out.
> >
> > That implies it's not getting an address. Thinking about it maybe
> > you can't
> > have both RedBoot and the app getting an addr from DHCP. Perhaps give
> > RedBoot a static address to see.
> >
> > Anyone else confirm?
>
> After reading a previous post from Hugo, I changed RedBoot to have a
static
> IP and gateway address.  The same thing happens when I do this.

>Uh, you have called "init_all_network_interfaces()" in you app?  The
>network doesn't initialize automatically - precisely to allow for the
>flexibility we've been discussing.  I mean, the dhcp thread will manage
>your leases *after the interfaces are brung up* but it won't initiate the
>bringup.

>I do advise staying with the static IP for RedBoot.

Sorry I couldn't get back to you yesterday.

I have the call to init_all_network_interfaces in my application properly -
as stated in the networking documentation.  I have the call in a thread that
gets created from my cyg_user_start routine.  Is there any additional
consideration I need to take into account for the call?

I have configured RedBoot to use a static IP address.

I am still running into the same problem as I mentioned before where the
network usage gets printed out on the GDB console window, then the hour
glass sits there for a while, and then the debugger shows program stopped at
the bottom.

Re: [ECOS] RE: RedBoot

[Hugo Tyson]

"Anthony Massa" <amassa@san.rr.com> writes:
> >Uh, you have called "init_all_network_interfaces()" in you app?  The
> >network doesn't initialize automatically - precisely to allow for the
> >flexibility we've been discussing.  I mean, the dhcp thread will manage
> >your leases *after the interfaces are brung up* but it won't initiate the
> >bringup.
> 
> I have the call to init_all_network_interfaces in my application properly -
> as stated in the networking documentation.  I have the call in a thread that
> gets created from my cyg_user_start routine.  Is there any additional
> consideration I need to take into account for the call?

No, that all sounds like you're doing exactly the right thing.

For comparison, you could enable CYGPKG_NET_BUILD_TESTS to let the system
build the network tests, then try ping_test for example.  That brings up
all interfaces using whatever means is configured, then pings the "server"
- in your configuration this should mean uses DHCP then pings the DHCP
server or the boot server that DHCP suggested.

If that fails, try configuring static IP addresses (distinct from the one
you have to RedBoot) for the build and try the same test; this tells us
whether it's the whole network being bad or just the DHCP processing.

> I have configured RedBoot to use a static IP address.
> 
> I am still running into the same problem as I mentioned before where the
> network usage gets printed out on the GDB console window, then the hour
> glass sits there for a while, and then the debugger shows program stopped at
> the bottom.

Has the program really stopped?  Does the debugger tell you where?

I can only suggest you breakpoint and step through
init_all_network_interfaces() and see where it's hanging up, sorry.  And of
course compare with the behaviour of the network testcases.

	- Huge

[ECOS] Re: RedBoot

[Anthony Massa]

I tried to run the tests by first selecting Build->Tests.  Then Tools->Run
Tests, which brought up an error dialog to add the mbx platform, which I
did.  Then I selected the tests to run, connected to my target via TCP
(using my static address in RedBoot).

However, each time I tried I got this message - no matter what test I ran:

*** 21:00:17 Run started
[ 13 Th 21:00:18] Couldn't get process information!
Failed to run "" - The system cannot find the file specified.

*** 21:00:22 Run complete

The same thing happened when I tried to connect via serial port as well.
What am I doing wrong?


Not being able to run the tests, I tried to get more insight as to where my
application was failing.  I find that it is failing in the function
quicc_eth_init in if_quicc.c.  This is called from cyg_net_init, in the for
loop after the thread (cyg_netint) is created and started.  I have had some
troubles with GDB crashing while stepping through various parts of the
quicc_eth_init routine - once it crashed when stepping over HAL_DCACHE_SYNC.
It seems to have problems with the cyg_drv_interrupt_unmask function call.

Any suggestions?

--Anthony

[ECOS] Re: RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I tried to run the tests by first selecting Build->Tests.  Then Tools->Run
> Tests, which brought up an error dialog to add the mbx platform, which I
> did.  Then I selected the tests to run, connected to my target via TCP
> (using my static address in RedBoot).
> 
> However, each time I tried I got this message - no matter what test I ran:
> 
> *** 21:00:17 Run started
> [ 13 Th 21:00:18] Couldn't get process information!
> Failed to run "" - The system cannot find the file specified.
> 
> *** 21:00:22 Run complete

Perhaps the cygwin tools aren't in the path. Have you installed the .reg
file mentioned in "Updated configuration tools for Windows" at
http://sources.redhat.com/ecos/anoncvs.html ?

> Not being able to run the tests, I tried to get more insight as to where my
> application was failing.  I find that it is failing in the function
> quicc_eth_init in if_quicc.c.  This is called from cyg_net_init, in the for
> loop after the thread (cyg_netint) is created and started.  I have had some
> troubles with GDB crashing while stepping through various parts of the
> quicc_eth_init routine - once it crashed when stepping over HAL_DCACHE_SYNC.
> It seems to have problems with the cyg_drv_interrupt_unmask function call.

Looking at it, the problem may be that the interrupts are set up so near
the start. This means that any interrupts received before the init function
finishes could lead to problems because the rest of the driver hasn't been
initialised. And if RedBoot had been using the eth device, interrupts
_would_ already be enabled.

Try setting up the interrupt handling much closer to the end, or perhaps
just try turning off interrupts throughout that function just to see if
that helps.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] Re: RedBoot

[Anthony Massa]

>Perhaps the cygwin tools aren't in the path. Have you installed the .reg
>file mentioned in "Updated configuration tools for Windows" at
> http://sources.redhat.com/ecos/anoncvs.html ?

I'll give that a try. I didn't notice the reg file back when I switched to
ConfigTool 1.3.1.2.

>> Not being able to run the tests, I tried to get more insight as to where
my
>> application was failing.  I find that it is failing in the function
>> quicc_eth_init in if_quicc.c.  This is called from cyg_net_init, in the
for
>> loop after the thread (cyg_netint) is created and started.  I have had
some
>> troubles with GDB crashing while stepping through various parts of the
>> quicc_eth_init routine - once it crashed when stepping over
HAL_DCACHE_SYNC.
>> It seems to have problems with the cyg_drv_interrupt_unmask function
call.



>Looking at it, the problem may be that the interrupts are set up so near
>the start. This means that any interrupts received before the init function
>finishes could lead to problems because the rest of the driver hasn't been
>initialised. And if RedBoot had been using the eth device, interrupts
>_would_ already be enabled.

>Try setting up the interrupt handling much closer to the end, or perhaps
>just try turning off interrupts throughout that function just to see if
>that helps.


I'll move the interrupt creation and unmasking to the end of the
quicc_eth_init function and see what happens. I'm not sure about that
because I have seen it fail at various points through that routine.  If that
doesn't work I'll give globally turning off interrupts a try and see where
that leads - although, won't that have an effect on GDB's communication?

I'm a little confused how the Ethernet switch over occurs since I'm
debugging over the Ethernet port as well.  Basically, RedBoot is receiving
debug packets from GDB over the Ethernet port while I am stepping through
the quicc_eth_init routine to setup control of the same Ethernet port for
the application.

--Anthony

[ECOS] Re: RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> >Perhaps the cygwin tools aren't in the path. Have you installed the .reg
> >file mentioned in "Updated configuration tools for Windows" at
> > http://sources.redhat.com/ecos/anoncvs.html ?
> 
> I'll give that a try. I didn't notice the reg file back when I switched to
> ConfigTool 1.3.1.2.

It wasn't there before a few days ago :-).
 
> >> Not being able to run the tests, I tried to get more insight as to where
> my
> >> application was failing.  I find that it is failing in the function
> >> quicc_eth_init in if_quicc.c.  This is called from cyg_net_init, in the
> for
> >> loop after the thread (cyg_netint) is created and started.  I have had
> some
> >> troubles with GDB crashing while stepping through various parts of the
> >> quicc_eth_init routine - once it crashed when stepping over
> HAL_DCACHE_SYNC.
> >> It seems to have problems with the cyg_drv_interrupt_unmask function
> call.
> 
> >Looking at it, the problem may be that the interrupts are set up so near
> >the start. This means that any interrupts received before the init function
> >finishes could lead to problems because the rest of the driver hasn't been
> >initialised. And if RedBoot had been using the eth device, interrupts
> >_would_ already be enabled.
> 
> >Try setting up the interrupt handling much closer to the end, or perhaps
> >just try turning off interrupts throughout that function just to see if
> >that helps.
> 
> I'll move the interrupt creation and unmasking to the end of the
> quicc_eth_init function and see what happens. I'm not sure about that
> because I have seen it fail at various points through that routine.  If that
> doesn't work I'll give globally turning off interrupts a try and see where
> that leads - although, won't that have an effect on GDB's communication?

Only for the duration of that function (obviously reenable the interrupts
at the end!). You may need to step over it instead.
 
> I'm a little confused how the Ethernet switch over occurs since I'm
> debugging over the Ethernet port as well.  Basically, RedBoot is receiving
> debug packets from GDB over the Ethernet port while I am stepping through
> the quicc_eth_init routine to setup control of the same Ethernet port for
> the application.

There's magic in the "common" ethernet driver layer, in io/eth. Basically
redboot gets a sneaky look at every packet that comes in.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] Re: RedBoot

[Anthony Massa]

The .reg file helped out.  Now the tests run fine.

However, the ping_test still had the same result as running my application,
where it would try to initialize the Ethernet port and the board would hang.
Then the Config Tool would disconnect from the target.

The other things I tried were:

- Moving the creation of the interrupt in quicc_eth_init to the end of the
routine.  This failed with the same outcome as before.

- I removed a line (shown below) in the quicc_eth_init because of the
comment of shutting down the Ethernet.  I thought this would have been the
problem since I was debugging using the Ethernet port, and obviously,
shutting it down would be very bad.  This failed with the same outcome as
before, too.

    // Shut down ethernet, in case it is already running
    scc->scc_gsmr_l &= ~(QUICC_SCC_GSML_ENR | QUICC_SCC_GSML_ENT);


- I disabled interrupts at the beginning of the quicc_eth_init routine using
HAL_DISABLE_INTERRUPTS and re-enabled them at the end using
HAL_RESTORE_INTERRUPTS.  This failed and hung the board the same way as
before.

- I also tried using a static IP address.  I didn't think this would work
since the failure occurs way before the IP address is used.  This failed as
well.


It seemed as though the failure was occurring when the code tried to access
the volatile struct ethernet_pram *enet_pram variable in quicc_eth_init.  It
was hard to be absolutely certain because there were some failures that
occurred at different points in the routine, but it seemed that the code
that used this variable caused the most immediate failures.  I don't know if
there is some sort of contention problem with accessing the Ethernet
registers while RedBoot/GDB is running or what.

I did try to run while stepping through the quicc_eth_init routine and also
just running without any breakpoints, however, the hung board result was the
same in both running modes.

Do you have any additional insight for this problem?  I really appreciate
your help.

--Anthony