NDK Raw Ethernet, not really raw?

Mitch,

As we've already discussed via email, I'm posting the solution to this thread so that others may find this if they run into the same problem. Can you please mark this thread as "verified answer?"

-------------------------------------- original email of solution ------------------------------------------------

Mitch,

I think I am getting close to getting the driver in promiscuous mode.  I wanted to share what I know now, in case you wanted to try on your end.

First off, we’ve found the following doc:

http://focus.ti.com/lit/ug/sprufl5b/sprufl5b.pdf

5.21 Receive Multicast/Broadcast/Promiscuous Channel Enable Register

(RXMBPENABLE)

Looking at the above section, there’s a table that has some bits that we want to set:

The RXPROMCH bit in RXMBPENABLE selects the promiscuous channel to receive frames selected by

the RXCMFEN, RXCSFEN, RXCEFEN, and RXCAFEN bits. These four bits allow reception of MAC

control frames, short frames, error frames, and all frames (promiscuous), respectively.

Also from the doc:

2.10.8 Promiscuous Receive Mode

When the promiscuous receive mode is enabled by setting the RXCAFEN bit in the receive

multicast/broadcast/promiscuous channel enable register (RXMBPENABLE), nonaddress matching frames

that would normally be filtered are transferred to the promiscuous channel. Address matching frames that

would normally be filtered due to errors are transferred to the address match channel when the RXCAFEN

and RXCEFEN bits in RXMBPENABLE are set. A frame is considered to be an address matching frame

only if it is enabled to be received on a unicast, multicast, or broadcast channel. Frames received to

disabled unicast, multicast, or broadcast channels are considered nonaddress matching.

MAC control frames address match only if the RXCMFEN bit in RXMBPENABLE is set. The RXCEFEN

and RXCSFEN bits in RXMBPENABLE determine whether error frames are transferred to memory or not,

but they do not determine whether error frames are address matching or not. Short frames are a special

type of error frames.

A single channel is selected as the promiscuous channel by the RXPROMCH bit in RXMBPENABLE. The

promiscuous receive mode is enabled by the RXCMFEN, RXCEFEN, RXCSFEN, and RXCAFEN bits in

RXMBPENABLE. Table 5 shows the effects of the promiscuous enable bits. Proper frames are frames

that are between 64 bytes and the value in the receive maximum length register (RXMAXLEN) bytes in

length inclusive and contain no code, align, or CRC errors.

So, given all of this, I’ve tried the following.  I’m having some issues verifying whether or not the driver is actually in promiscuous mode or not, but I though I’d share these steps in case you want to try it on your end:

Here’s the steps:

1. increase the size of the receive buffers by A LOT (in ethdriver.c)

#define     PKT_MAX                     190          // à  previously this was 64

1. Add this flag EMAC_CONFIG_MODEFLG_PASSALL to ModeFlags (ethdriver.c)

    ecfg.ModeFlags             = EMAC_CONFIG_MODEFLG_RXOFFLENBLOCK |

                                 EMAC_CONFIG_MODEFLG_RMII |

                                 EMAC_CONFIG_MODEFLG_PASSALL;

   ecfg.MdioModeFlags         = MDIO_MODEFLG_AUTONEG;

1. Updated the EmacStart() function (nimu_eth.c):

        /* Set the 'initial' Receive Filter */

        // ptr_pvt_data->pdi.Filter = ETH_PKTFLT_MULTICAST;  // previous value

        ptr_pvt_data->pdi.Filter = EMAC_RXFILTER_ALL;

       setting the above results in the following code being run in EMAC_setReceiveFilter():

    if (ReceiveFilter == EMAC_RXFILTER_ALL){

        CSL_FINST(EMAC_REGS->RXMBPENABLE, EMAC_RXMBPENABLE_RXCAFEN, ENABLE);

        CSL_FINS( EMAC_REGS->RXMBPENABLE, EMAC_RXMBPENABLE_RXPROMCH, masterChannel);

    }

Regards,

Steve

below is the original files sent from this email:

8284.promisc01.zip

below contains further updates, however they are unverified by the customer:

7522.promisc02.zip