Problems initializing Network driver on MCF5235 Coldfire
CWolfe at motioncontrol.org
CWolfe at motioncontrol.org
Thu Jun 21 14:46:41 UTC 2007
On 21 Jun 2007 at 9:30, Joel Sherrill wrote:
> CWolfe at motioncontrol.org wrote:
> > On 21 Jun 2007 at 8:57, Joel Sherrill wrote:
> >
> >
> >> CWolfe at motioncontrol.org wrote:
> >>
> >>> I Forwarded my responses to the list, but I'll summarize what's going
> >>> on....
> >>> I can compile/upload/execute all(I believe) of the samples from the
> >>> testsuites.
> >>> when I try to initialize the network using a non-loopback interface,
> >>> the execution
> >>> dips into some black hole where I can't trace it. I have been able to
> >>> trace the code into
> >>>
> >>> http.c::init()
> >>> |--rtems_glue.c::rtems_bsdnet_initialize_network()
> >>> |--rtems_glue.c::rtems_bsdnet_initialize()
> >>> | |--rtems_glue.c::bsd_init()
> >>> | |-- blah blah blah <makes it past all of this>
> >>> |
> >>> |--rtems_glue.c::rtems_bsdnet_attach(ifp)
> >>> | |-- blah blah blah <makes it past all of this>
> >>> | |--rtems_glue.c::rtems_bsdnet_setup()
> >>> |
> >>> |--rtems_glue.c::rtems_bsdnet_ifconfig()
> >>> |---rtems_glue.c::rtems_bsdnet_semaphore_obtain()
> >>> |-- blah blah blah <makes it past call to ioctl which I
> >>> believe "UP"s the interface...???>
> >>> |---rtems_glue.c::rtems_bsdnet_semaphore_release()
> >>> <======here it dies, on/while returning
> >>> from semaphore_release()>
> >>>
> >>> but i can't trace any further into it. At Joel's Suggestion, I added
> >>> some LEDs to the board to use in trouble shooting, but as of right
> >>> now, I don't know where in the code to look/place debugging code...
> >>>
> >> How does it die?
> >>
> >> Do you have USE_FTPD or USE_HTTPD defined in your init.c?
> >>
> > I have both defined
> >
> Remember KISS -- Keep It Simple Stupid. :-D
>
> Only define one at a time until you have them both working.
> Then define both.
Have tried with only httpd and with only ftpd .... both produce the same result.....
> >> The Init task for this application deletes itself after starting the
> >> services you have conditionally defined. If you don't have any
> >> defined, it will fall into the idle loop and probably not do much
> >> besides respond to pings.
> >>
> > it does nothing.... I believe it ends up executing a jump or branch into
> > unused memory, causing an invalid opcode to be executed, but that's
> > speculation sinsce I can't see into what's going on.
> >
> Sounds like a misconfigured,
^^^^ My hunch says it's a misconfiguration on my part, but I am not savy
enough to know where and how .......
misinstalled, or spurious interrupt.
>
> Do you have a spurious interrupt handler in the BSP which attempts
> to printk something useful?
possibly, though I haven't inserted anything that wasn't in the most recent BSP from the
rtems ftp site. That's what drives me nuts, is that this is the most plain vanilla net app, and it
crashes basically out-of-the-box. There are some in-house mods we do to the bsp to support
a bootstrapper for "frmware upgrades", BUT.... at the moment, I'm not implementing those
modifications...
I tried the loopback test and it runs successfully, but the netdemo application crashes the
same way the others do. Any app that calls rtems_bsdnet_initialize_network() fails after
outputting "fs1 : 00:80:7F:22:61:77"....
it actually makes it a little farther than that, but this is the last output on the console.
> >> I would make the LED blink in the NIC's ISR.
> >>
> >> netdemo is easier to debug network problems with. It doesn't
> >> have as much going on. Switch to it... ping the target.. then
> >> when that works telnet to the ports it echoes on.
> >>
> > I will try it and see.
> >
> >> --joel
> >>
> >>
> >> Do
> >> --joel
> >>
> >>> Thank you for your time.
> >>> Christopher Wolfe
> >>> Motion Control Systems, Inc.
> >>>
> >>> On 21 Jun 2007 at 17:17, Chris Johns wrote:
> >>>
> >>>
> >>>> Hi Chris,
> >>>>
> >>>> Please cc me with responses. I know the Coldfire and the driver well
> >>>>
> >>> enough to
> >>>
> >>>> aid you in getting the web server to work.
> >>>>
> >>>> Regards
> >>>> Chris
> >>>>
> >>>> Joel Sherrill wrote:
> >>>>
> >>>>> CWolfe at motioncontrol.org wrote:
> >>>>>
> >>>>>> On 20 Jun 2007 at 9:36, Joel Sherrill wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I actually don't have a 5235 so I have cc'ed Chris Johns since
> >>>>>>> I think he is way more familiar with the Coldfire BSPs.
> >>>>>>>
> >>>>>>> This type of question is usually best asked on the list. There
> >>>>>>> are many people out there who and more eyes is good.
> >>>>>>>
> >>>>>>>
> >>>>>> what is the address to send to?
> >>>>>>
> >>>>>>
> >>>>> You have to be subscribed... see
> >>>>> http://www.rtems.org/wiki/index.php/RTEMSMailingLists
> >>>>> for instructions.
> >>>>>
> >>>>> If you spot something wrong in the Wiki, feel free
> >>>>> to create an account and fix it.
> >>>>>
> >>>>>
> >>>>>>> My usual first questions are:
> >>>>>>>
> >>>>>>> + Can you run ticker?
> >>>>>>>
> >>>>>>>
> >>>>>> haven't tried yet, will do so now.
> >>>>>>
> >>>>>>
> >>>>> If the clock tick interrupt isn't working, then
> >>>>> things aren't in good shape.
> >>>>>
> >>>>>>> + Can you run netdemo?
> >>>>>>>
> >>>>>>>
> >>>>>> no, same issue with crashing on driver init (after releasing
> >>>>>>
> >>> semaphore)
> >>>
> >>>>>>
> >>>>>>
> >>>>> Maybe you are dying in the interrupt handler. Do you have some type of
> >>>>> exception handler of debugger
> >>>>> that can point you to an address. If not, do you have
> >>>>> an LED you could blink or some other bread crumb
> >>>>> you could post to note you entered the ISR.
> >>>>>
> >>>>>>> + Are you using RPMs or your own tool builds.
> >>>>>>>
> >>>>>>>
> >>>>>> using cygwin so....
> >>>>>> own build tools. versions and patches are as follows <excerpted from
> >>>>>> our in-house toolchain build script>......
> >>>>>> GCC=gcc-4.1.1
> >>>>>> BINUTILS=binutils-2.17
> >>>>>> NEWLIB=newlib-1.14.0
> >>>>>> BDM=m68k-bdm-1.3.0
> >>>>>> GDB=gdb-6.0
> >>>>>> INSIGHT=insight-6.0
> >>>>>> AUTOCONF=autoconf-2.61
> >>>>>> AUTOMAKE=automake-1.10
> >>>>>> i'm actually not sure which patches have been appplied as the script
> >>>>>> automatically applies them. if necessary, i can dig into them and
> >>>>>> figure out which ones are actually applied, but i assume they are the
> >>>>>> most recent...
> >>>>>>
> >>>>>>
> >>>>> Are you sure about newlib 1.14? The 4.7 branch
> >>>>> should be built against 1.15.
> >>>>>
> >>>>> This isn't likely to be your problem but normally
> >>>>> RTEMS versions are carefully matched against
> >>>>> a specific newlib version and patch.
> >>>>>
> >>>>>>> CWolfe at motioncontrol.org wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Dear Joel, My name is Christopher Wolfe, and I am an Intern
> >>>>>>>> working for Motion Control Systems. Currently, I am working on an
> >>>>>>>> embedded management project with the coldfire 5235BCC eval board. I
> >>>>>>>> am having trouble with getting the webserver up and running, and I
> >>>>>>>> was wondering if you might know what I could do next to find the
> >>>>>>>> problem. I have based my code off of the http example, but I have
> >>>>>>>> had to make a few minor modifications to allow it to compile, as
> >>>>>>>> directories and whatnot are moved, etc. Anyway, when I upload the
> >>>>>>>> code and run it, it crashes in the network driver initialization. I
> >>>>>>>> have traced the execution as far into the code as I am able, but I
> >>>>>>>> lose track at specific point.
> >>>>>>>> execution makes it thru:
> >>>>>>>> http.c::init()
> >>>>>>>> |--rtems_glue.c::rtems_bsdnet_initialize_network()
> >>>>>>>> |--rtems_glue.c::rtems_bsdnet_initialize()
> >>>>>>>> | |--rtems_glue.c::bsd_init()
> >>>>>>>> | |--blah blah blah <makes it past all of this>
> >>>>>>>> |
> >>>>>>>> |--rtems_glue.c::rtems_bsdnet_attach(ifp) | |-- blah
> >>>>>>>>
> >>> blah
> >>>
> >>>>>>>> blah <makes it past all of this>
> >>>>>>>> | |--rtems_glue.c::rtems_bsdnet_setup()
> >>>>>>>> |--rtems_bsdnet_ifconfig()
> >>>>>>>> |---rtems_glue.c::rtems_bsdnet_semaphore_obtain()
> >>>>>>>> |--blah blah blah <makes it past call to ioctl which I
> >>>>>>>> believe "UP"s the interface...???>
> >>>>>>>> |---rtems_glue.c::rtems_bsdnet_semaphore_release()
> >>>>>>>>
> >>> <here
> >>>
> >>>>>>>> it dies>
> >>>>>>>>
> >>>>>>>> as soon as the semaphore is released, i lose track of the execution
> >>>>>>>> of the code. where it should return to rtems_bsdnet_ifconfig(), it
> >>>>>>>> is not. debugging printf statements were placed as the very last
> >>>>>>>> statement inside the semaphore release code, and the first
> >>>>>>>>
> >>> statement
> >>>
> >>>>>>>> in rtems_bsdnet_ifconfig() after the call to release the semaphore.
> >>>>>>>> of the the two statements which should be executed, only the first
> >>>>>>>> is executed. afterwards, execution progresses into the
> >>>>>>>> rtems_bsdnet_semaphore_release's exit code.... never to return to
> >>>>>>>> the calling function .... and hence it is lost and i can't trace
> >>>>>>>> it with the tools i have.....
> >>>>>>>>
> >>>>>>>> At this point in the initialization, what is going on? Are there
> >>>>>>>> other rtems processes which are taking control? where does the
> >>>>>>>> execution go after releasing that semaphore? what configuration
> >>>>>>>> issues could cause this symptom set?<<<i assume this to be the
> >>>>>>>> problem, but i just don't know enough about rtems yet>>>
> >>>>>>>>
> >>>>>>>> I include the configuration options/code i am using below.....
> >>>>>>>>
> >>>>>>>> <<changes to makefile>>
> >>>>>>>> LDFLAGS += -qnolinkcmds -T linkcmdsflash
> >>>>>>>> LD_LIBS += -lhttpd -lftpd
> >>>>>>>> <<changes to init.c>>
> >>>>>>>> #include <rtems/confdefs.h>
> >>>>>>>> #include <rtems/ftpd.h>
> >>>>>>>> << some printf()'s for debugging>>
> >>>>>>>> <<changes to system.h>>
> >>>>>>>> #include "tmacros" (file was not
> >>>>>>>> in include directory, but I copied it from the testsuites build
> >>>>>>>> directory)
> >>>>>>>>
> >>>>>>>>
> >>> =======================================================================
> >>>
> >>>>>>>> otherwise, everything is the same as the example source. I am using
> >>>>>>>> rtems 4.7.1. Thank you for your time, and I would greatly
> >>>>>>>>
> >>> appreciate
> >>>
> >>>>>>>> any help you could give.
> >>>>>>>> Best Regards,
> >>>>>>>> Christopher Wolfe
> >>>>>>>> Motion Control Systems, Inc.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>
> >>> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> rtems-users mailing list
> >>> rtems-users at rtems.com
> >>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>>
> >>>
> >
> >
> >
>
More information about the users
mailing list