Problems initializing Network driver on MCF5235 Coldfire

[CWolfe at motioncontrol.org]

On 26 Jun 2007 at 13:53, Alan Cudmore wrote:
Alan,
> Chris,
> 
> How are you loading your RTEMS code on this board?
> 
via cfflasher 3.1 under windows with pemicro parallel bdm cable

> I have the same board, and I can run all of my RTEMS demos on it when  
> I load via BDM.
> 
> I have the following setup:
> - RTEMS 4.7
> - GCC 4.1.1 tools for the Coldfire ( Linux RPMS from RTEMS site )
> - GDB with RTEMS and BDM patches
> - unmodified mcf5235 BSP
same with the exception that I have been adding debugging statements to the bsp to trace 
the error.
> 
> All of my code works when I download it into RAM using GDB over the  
> BDM connection.
i don't have a handy way to do this directly. since I am using a parallel port that is not 
integrated with bios, I haven't been able to get cygwin/gdb/bdm to connect to the device
> When I load an RTEMS program into flash and boot directly to that  
> ( using the jumper to disable the Dbug monitor ), the non-network  
> programs work fine, but the network demos die exactly how you describe.
> 
> Also, downloading code into RAM using TFTP does not work for me ( not  
> even the RTEMS hello example )
> 
> Because I would like to be able to boot my RTEMS apps from flash, but  
> I dont want to keep the code in flash, I will either:
> - modify the BSP startup to copy code from flash to RAM , or
> - make a small bootstrap program to copy an RTEMS RAM image from  
> FLASH to RAM.
> Hopefully the network demos will work for that.
when I began working on this project, I started by adding the network support to an existing 
project which already had bootstrapping code to copy from flash to ram. the bootstrapping 
occurred at a layer lower than rtems in a customized bsp. I uncovered the problem with the 
network code at that time. Fearing some conflict in that code, I started working with the plain-
vanilla BSP code. So then, Having had the network initialization run from ram, this doesn't 
seem to be the problem, but there are enough variables that I couldn't say for sure.  


What I know so far is that as soon as the recieve buffer descriptors are made available to the 
fec, the fec tries to do something with them and ends up crashing the cpu.
I don't have much visibility into what's going on after that because hardware interrupts get 
triggerred and whatever it is doing in there is virtually invisible, and the bdm cable breaks 
communication with the board at that point.
Is it a DMA problem?
is it a matter of alignment of buffer descriptors?
is it a problem of invalid buffer descriptor allocation?  >> maybe allocation attempts to put in 
		flash area?
If I could know what interrupt/mask is generated I would know more, but I can't see that far 
into it. 
Currently i am writing a hook on the fec's interrupt to debug....




Chris Wolfe
Motion Control Systems, Inc. 


> 
> Alan
> 
> 
> 
> On Jun 21, 2007, at 7:44 PM, Chris Johns wrote:
> 
> > CWolfe at motioncontrol.org wrote:
> >> On 21 Jun 2007 at 9:55, Joel Sherrill wrote:
> >>
> >> 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.
> >
> > I would agree with this.
> >
> > A simple test is to find the bit of code that unmasks the  
> > interrupts for the
> > FEC and comment it out. If the board does not crash it would seem  
> > the handler
> > is the cause. It will not work but that is next.
> >
> >>
> >>> 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......
> >>
> >
> > Is it possible to get a BDM gdb debugger working on your board ?
> >
> > If you could it would make things simpler to debug.
> >
> > Regards
> > Chris
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >
>