MCF5307C3 NE2000 Network Driver

Chris Xenophontos cxenophontos at
Thu Jun 3 19:37:11 UTC 2004


The code to unmask EINT3 was commented out in our _version_ of network.c, as
was the AVEC assignment.  I put these back in, and rebuilt.  Perhaps my copy
of network.c is way out of date(?).

The application hangs as soon as the interrupt is unmasked.

I hooked up a logic analyzer, and verified that we do enter the ISR right
before the hang  ( ns8390_interrupt_handler in ns8390.c )  It appears that
we enter _Internal_error_Occurred, which of course, halts the system.

It also seems that we are entering _Internal_error_Occurred from a call to

A register dump at time of hang is as follows:
D0=00000012,  A0=00000000
D1=DEADBEEF,  A1=00000001
D2=00000700,  A2=0015ABC0
D3=00000012,  A3=00164750
D4=00000000,  A4=001647D0
D5=00000000,  A5=0006FF3A
D6=00000001,  A6=00164758
D7=00000000,  A7=00164724
PC=0003D444 = end of Internal_error_Occurred

SP is as follows:
0004CED4  (within rtems_semaphore_obtain)

I'll keep working this, and will post any progress.


-----Original Message-----
From: Ian Caddy [mailto:ianc at] 
Sent: Wednesday, June 02, 2004 9:21 PM
To: Chris Xenophontos
Cc: rtems-users at
Subject: Re: MCF5307C3 NE2000 Network Driver

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,
> 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
> vector table.  
> I'll post again as I gather more information --
> Thanks
> Chris
> -----Original Message-----
> From: Ian Caddy [mailto:ianc at] 
> Sent: Tuesday, June 01, 2004 8:56 PM
> To: Chris Xenophontos
> Cc: rtems-users at
> 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:  
>>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
>>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
>>Has any more progress been made on this network driver?  Any help would be
>>greatly appreciated.
>>Chris Xenophontos
>>cxenophontos at

More information about the users mailing list