You are not logged in.
We are implementing a TDMA mac and here are a few observations/questions :
1. In warpmac_pollEthernet( ), why are the timer interrupt and the phy good header interrupt disabled ?
2. With ref design 11.2, the following problem is seen
- An ethernet packet is received; When good header interrupt is re-enabled in warpmac_pollEthernet,
a good header interrupt is immediately received.
- however, warpphy_pollRxStatus() is always returning INCOMPLETE and basically hangs the mac under test.
- it seems that if the good header interrupt had arrived earlier, before the emacRx_callback( ) is invoked, the warpphy_pollRxStatus( )
does not hang, and MAC operation is not interrupted.
3. Since timer interrupts are disabled for a while in warpmac_pollEthernet( ), this also results (in the event of a hang situation
in warpphy_pollRxStatus ) in the MAC missing its tdma time slot - as a side-effect. Masking timer interrupts would also result in
non-deterministic delays in determining the start of the time slot ??
Any insight will be v. welcome !
Offline
1) We wanted to assure that the call to emacRx_int_handler() wouldn't be interrupted, as it manipulates some registers in the EMAC and initiates the DMA transfer of the received packet. This may not be strictly necessary, but was part of our effort to minimize the potential for unexpected/bad states in the code.
2) Does this happen every time the good header interrupt is re-enabled, or just occasionally? It might be related to a bug we fixed in v12.0, wherein the PHY would erroneously assert the good pkt interrupt when a received header indicated a packet length shorter than 24 bytes (i.e. shorter than a header). In phyRx_goodHeader_int_handler(), try checking the length in the received header (after the memcpy from the PHY) to see if it's valid.
3) Yeah, this is true. The timers keep running in hardware, even if they're not being polled. But the time required for software to act on a timer expiration will depend on where the processor is in the program when the timer expires. One way to minimize this would be to have just the timer control the program flow (i.e. only poll the emac/phy when the timer reaches certain values).
Offline
Reg point 2 - it seems to happen occasionally. Will check the header length as suggested.
If there are any other observed 'signatures' for spurious interrupts, could you kindly post ?
Offline