Problems initializing Network driver on MCF5235 Coldfire
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Jun 21 14:55:35 UTC 2007
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.
Are you on a private network with just the development machine
and target board?
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.
There are two tasks and a couple of interrupt_handler's in the driver.
You need to know which of them runs.
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