Problems initializing Network driver on MCF5235 Coldfire

CWolfe at motioncontrol.org CWolfe at motioncontrol.org
Thu Jun 21 15:09:19 UTC 2007


On 21 Jun 2007 at 9:55, Joel Sherrill wrote:

> CWolfe at motioncontrol.org wrote:
> > 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 .......
> >
> >
> >   
> The network driver is for an on-CPU FEC and the interrupt
> vector appears to be hard-coded to match the CPU expectations.
> It that is NOT correct for your board, then it will die as you describe.
I assume the BSP is setup correctly, because the author of the BSP was using the same 
board/setup/etc and had the device serving webpages at some point in the past.....
> 

> Are you on a private network with just the development machine
> and target board? 
Yes, though network is disconnected while I troubleshoot execution.... Once I know I have 
network initialization, I will reconnect.....
> 
> I suspect that you have a misconfigured interrupt.
> >  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.
> >
> >
> >   
> Change the printf to a printk... You are near the bottom of the network
> driver initialization. 
> 
this has been done. I have also added debugging staterments inside most of the functions in 
rtems_glue.c that pertain to network initialization.....
I would assume that the problem exists only either the BSP or in my code, and not in the 
rtems code, but i'm a bit lost in tracking the problem's origin.

> There are two tasks and a couple of interrupt_handler's in the driver.
> You need to know which of them runs.
i will add some more debugging statements and try to find out......

> 
> Beyond this.. maybe Chris has
> >>>> 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