(Fwd) Re: Problems initializing Network driver on MCF5235 Cold

[CWolfe at motioncontrol.org]

------- Forwarded message follows -------
CWolfe at motioncontrol.org wrote:
> On 20 Jun 2007 at 9:56, 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.
>>
>>     
> Done. Should I move this conversation  to that address...????
>   
Yeah.. it would give you more eyes.
>> 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?
ticker now tested and output is correct...
>>>>     
>>>>         
>>> haven't tried yet, will do so now.
>>>   
>>>       
>> If the clock tick interrupt isn't working, then
>> things aren't in good shape.
>>     
>>>   
>>>       
> since rtems tree was built without the testsuites, i am rebuilding with testsuites so i can build 
> ticker sample...
>   
>>>> + 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.
>>     
>
> To my knowledge there is no dedicated LED on the board, but I could
> throw one on somewhere, I'm sure....
> My debugging SW loses the execution at that point.... because i don't have an address to tell 
> it to go to, and whatever it is doing is jumping around a lot, The debugger is approximately 
> useless. All the same, where should I be blinking the light from code-wise? My problem is 
> that I don't see where the execution is going in the crack between the end of one function 
> and the statement following the call thereunto....
>   
It could be going to the IDLE task.  But my gut feeling is that the first
NIC interrupt is killing you.  Do you get an exception backtrace printed?
----
I get no output after it outputs the MAC addy. 
---
Is Mike Bertosh still around?
He is the fellow who wrote the BSP originally
---
Unfortunately, he is not available... 

mbertosh at motioncontrol.org
>>>   
>>>       
>>>> + 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.
>>
>>     
>
> Yes, i am using 1.15. there was a typo in the file...
>
>   
>> 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. 
>>>>>
>>>>> 	
>>>>>
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>
>   

------- End of forwarded message -------