MCF5307C3 NE2000 Network Driver

[Ian Caddy]

Hi Chris,

I am not quite sure what you mean by the VB reg is set to 0x6C.  Do you 
mean the Vector Base Register?  Your vecotr table will start at the 
Vector Base Register address, and the vector you are interested in is at 
offset 0x6C which is vector number 27.

I was just having a quick look through the original SBC5307 code and in 
the file sbc5307.h in include it states the NIC_IRQ as level 4 but the 
vector number is correct at 27, this is probably why the bit in the IMR 
is masked, but then looking a bit further on in the 
rtems_ne2000_driver_attach there is code to manually clear the IMR for 
EINT3 so unless this code has been removed, your IMR should be cleared.

If you have access to a BDM, then you should be able to set a breakpoint 
on the start of the ISR and check that it is going in there when the 
interrupt occurs.

Also, if you have a debugger, you should be able to stop the processor 
once it has hung and work out where it was, sounds like a bus error as 
that is the normal case for a hang on the 5307.

Hope this helps,

Ian Caddy
Microsol Aust Ptr Ltd

Chris Xenophontos wrote:

> Thanks Ian,
> 
> We verified that we are set up for Autovectoring.  IRQ3 is set to Level 3.
> The IMR is somehow set (masked) for IRQ3, and when we examine IPR bit 3, we
> see that IRQ3 is indeed pending.  
> 
> When I add a line in the app to explicitly unmask IRQ3, the system hangs
> right as IRQ3 asserts -  However, it appears to set the VB reg to 0x6C,
> which, as I understand is correct(?).  
> 
> Also, when I dump memory, the correct ISR address is installed in the RTEMS
> vector table.  
> 
> I'll post again as I gather more information --
> 
> Thanks
> Chris
> 
> 
> 
> 
> -----Original Message-----
> From: Ian Caddy [mailto:ianc at microsol.iinet.net.au] 
> Sent: Tuesday, June 01, 2004 8:56 PM
> To: Chris Xenophontos
> Cc: rtems-users at rtems.com
> Subject: Re: MCF5307C3 NE2000 Network Driver
> 
> Hi Chris,
> 
> We haven't worked directly with that board, but we use the 5307 and 
> there are a couple of things that you need to check to make sure 
> interrupts are working.
> 
> I assume that you are talking about an external interrupt, is it setup 
> for autovectoring?
> 
> Also if you have a BDM, you can check how the IMR is set or cleared (bit 
> 3 should be cleared) (it must be cleared for the interrupt to work, it 
> always gets me, I am used to a bit being set in the IMR to get my 
> interrupt, but not in this processor).
> 
> You can also check the IPR (interrupt pending register) to see if the 
> interrupt is pending (is bit 3 set?).  If it is, it is likely masked in 
> the IMR.
> 
> Also, you will need to check the value in IRQPAR which sets the IRQ3 to 
> either level 3 or level 6 interrupts.  If IRQPAR bit 6 is cleared, then 
> it is a level 3 interrupt and the info I gave you above is correct.  If 
> it is set, then it is a level 6 interrupt and you must look at different 
> bits in the IMR and IPR and the level 6 autovector must be filled in.
> 
> I hope this helps.
> 
> regards,
> 
> Ian Caddy
> 
> 
> 
> Chris Xenophontos wrote:
> 
> 
>>This is going back a few years, but has any further progress has been made
>>with D. Fiddes' NE2000/DM9008 network driver for the Coldfire 5307?
>>
>>I'm referring to the one at:  
>>http://sca.uwaterloo.ca/www.calm.hw.ac.uk/davidf/coldfire/rtems.htm
>>
>>We have taken the existing sbc5307/network directory, integrated it into a
>>BSP (RTEMS 4.6.0) for the MCF5307C3 Development board, built it, etc.
> 
> Upon
> 
>>initialization, (no bootp), we can observe the following:
>>
>>-driver attach is successful
>>-rtems_interrupt_attach returns successful
>>-tx, rx daemons initialize, and wait for events
>>-ARP request is seen on the network, with expected mac and Ethernet
>>addresses.
>>
>>It appears that the ISR (attached to IRQ3) never gets called.
>>
>>We've checked IRQ3 with an oscilloscope, which is seen to go low (active),
>>sometime after the ARP request, and stays low, meaning that it is still
>>masked(?)
>>
>>Has any more progress been made on this network driver?  Any help would be
>>greatly appreciated.
>>
>>
>>Thanks
>>Chris Xenophontos
>>cxenophontos at hammers.com
>>
>>
> 
> 
>