TMS570LS3137 with RMII

Is the PHY in RMII mode?

actually, there is no phy, it is connected to a switch chip with its port set to RMII

steven,

Did you change the MAC so that it is in RMII mode too? (special pinmux tab in HalCoGen?)

For the phy we used on one board, there was an option for the RMII clock that needed to be changed from the default over the MDIO interface in order to get the phy to work at all. Had to change the clock from the 1MHz to 50MHz through the managment interface. Maybe you've got some similar setting in the switch you are using.

in the PINMUX tab we have it set for RMII

we are feeding a clock of 50mhz from an oscillator directly to the TMS570LS3137 and the switch - 2 copies

its like the RMII output pins are not active at all

Ok, RMII works on this part so gotta be missing something.
Maybe send me your code and/or HalCoGen files and I'll look to see if I spot something.
Need to think about what it might be....

Hmm.

Are you getting stuck somewhere like in a loop on an MDIO read/write?

When you changed from the 'working' MII board ... did that board have the same switch just set in MII mode?
Or is it a different switch or different phy on the MII board?

There's an 'Enable MII' on the EMAC tab as well as the RMII/MII selection on the Pinmux tab.

Do you still have "Enable MII" set on the EMAC Global Tab?

Not sure what this does exactly.. But there's pin multiplexing for all the pins.... and then there is a bit to tell the MAC whether to output MII or RMII so I think this (second thing, the mac control) might be what the checkbox on the EMAC tab is tied to..

the ENABLE MII in the EMAC tab is not checked - and RMII in the PINMUX tab is set
the code also calls the function: EMACMIIDisable(uint32 emacBase)
which I added as LWIP was not calling this function but the emac.c init was

we send a packet out and we see no RMII pins toggle at all

also, we have the RMII_RX_ER unconnected, our understanding is that there is a pullup on the chip always active , do you concur?

Hi Steven,

So sounds like it's time to look at the MAC's registers to see what they tell you.

Maybe you can compare them between your working system and the not working.. to see if what the differences are.

our understanding is that there is a pullup on the chip always active ,

Should be a pulldown not pullup:

we send data to the emac and we do not get an interrupt - there is some mux setting that Halcogen is not setting up correctly for RMII
or RMII really does not work

in the pinmux.c there is this statement

PINMUX_ETHERNET_SELECT(RMII);

what does it do? the RMII #define I cant find

Steven,

It's defined in the top of the same file (pinmux.c) as a macro line 83:

#define PINMUX_ETHERNET_SELECT(interface)   \

           (pinMuxReg->PINMMR29 = (pinMuxReg->PINMMR29 & PINMUX_ETHERNET_MASK) | (PINMUX_ETHERNET_##interface))

And PINMUX_ETHERNET_RMII is  defined in pinmux.h line 650:

#define PINMUX_ETHERNET_RMII                    ((uint32)((uint32)0x1U <<  PINMUX_ETHERNET_SHIFT))

RMII works - I've used it before.  There could be an error in the latest HalCoGen although I wouldn't jump to that conclusion.

I think the thing to do is to start the register comparison of the EMAC.  Look at it's status flags, statistics, etc.

Compare against the working board you have.   Something will pop out.

If you have an HDK or Control Card from TI I think we could also look at making RMII work on one of these w. the LWIP demo ..

the example EMAC with LWIP is using MII - do you have a tested example of TMS570LS3137 enet code with RMII ?

Steven,

I've used the RMII mode before myself. I posted the 'Known Issues' and patch at the bottom of this page: processors.wiki.ti.com/.../HALCoGen_Ethernet_Driver_and_lwIP_Integration_Demonstration

and it looks like it was an RM46 control card that I had to patch the lwIP stack for.

If memory serves me the issue was that the bit 'RMIISPEED' in the 'MACCONTROL' register needs to be set by software because the RMII interface is a little different in 10MBps mode versus 100MBps mode. [I don't remember the exact difference - think it's the clock speed but might be something else. Shows up on a timing diagram].

Anyway that bit is set to default to 10Mbps and when porting to the RMII we had to add code that checked what speed the PHY had negotiated and then this RMIISPEED bit had to be set to match. It's something that's not needed in MII mode.

Which is why I'm thinking looking at the MAC's control registers and checking the differences is probably the next step here.

I can try to find that example -- I'm not sure if it ships with the HalCoGen lwIP examples or if I had to add a folder for the CNCD but either way it's still likely on my PC.

It wouldn't work for you directly on your board though because it's going to poll the PHY through MDIO to find out what speed to set the RMIISPEED bit to. You'd need to change that for your switch I think.. unless it's one of the IEEE standard regs.

-Anthony

For this kit:

The code i have is:

4848.RM46xCNCD.zip

I think it doesn't ship w. the lwIP demo because it's the only control card I have in my install folder.

I think I just copied the RM46x folder and modified the code for the control card.

F:\ti\Hercules\HALCoGen EMAC Driver with lwIP Demonstration\v00.03.00   is where that zip file goes ..

to recap

we have the RMII port of the TMS570 connected to a RMII port of a switch chip WITHOUT a phy interface  in between.

the MDIO bus is not used

we have compared the rmii mux settings against the demo code you sent and they are equivalent

we have checked the MAC registers - specifically MACCONTROL is set to 0x8001, the interrupt registers are enabled and the MAC chip is in IDLE

the LWIP (+freeRTOS) mac init + stackcode we are using has worked on the HDK board (with the DP83640 PHY) in MII (it appears this board supports MII only)

clock input is 50mhz

we cant see the TX pins toggle or the MAC set an interrupt when the switch sends data to it

is there some connection between the MAC and MDIO that would nbot let it work without a PHY ?

or what are we missing?

here is the mux init created by halcogen

void muxInit(void){

/* USER CODE BEGIN (1) */
/* USER CODE END */

/* Enable Pin Muxing */
kickerReg->KICKER0 = 0x83E70B13U;
kickerReg->KICKER1 = 0x95A4F1E0U;

/* USER CODE BEGIN (2) */
/* USER CODE END */

pinMuxReg->PINMMR0 = PINMUX_BALL_C3_I2C_SCL | PINMUX_BALL_B2_I2C_SDA;

pinMuxReg->PINMMR1 = PINMUX_BALL_E3_HET1_11 | PINMUX_BALL_E5_ETMDATA_20 | PINMUX_BALL_F5_ETMDATA_21;

pinMuxReg->PINMMR2 = PINMUX_BALL_C1_GIOA_2 | PINMUX_BALL_G5_ETMDATA_22 | PINMUX_BALL_E1_GIOA_3 | PINMUX_BALL_B5_GIOA_5;

pinMuxReg->PINMMR3 = PINMUX_BALL_K5_ETMDATA_23 | PINMUX_BALL_H3_GIOA_6 | PINMUX_BALL_L5_ETMDATA_24;

pinMuxReg->PINMMR4 = PINMUX_BALL_M1_GIOA_7 | PINMUX_BALL_M5_ETMDATA_25 | PINMUX_BALL_V2_HET1_01 | PINMUX_BALL_U1_HET1_03;

pinMuxReg->PINMMR5 = PINMUX_BALL_K18_HET1_0 | PINMUX_BALL_W5_HET1_02 | PINMUX_BALL_V6_HET1_05 | PINMUX_BALL_N5_ETMDATA_26;

pinMuxReg->PINMMR6 = PINMUX_BALL_T1_HET1_07 | PINMUX_BALL_P5_ETMDATA_27 | PINMUX_BALL_V7_HET1_09 | PINMUX_BALL_R5_ETMDATA_28;

pinMuxReg->PINMMR7 = PINMUX_BALL_R6_ETMDATA_29 | PINMUX_BALL_V5_MDCLK | PINMUX_BALL_W3_SCIRX | PINMUX_BALL_R7_ETMDATA_30;

pinMuxReg->PINMMR8 = PINMUX_BALL_N2_SCITX | PINMUX_BALL_G3_MDIO | PINMUX_BALL_N1_MIBSPI1NCS_4 | PINMUX_BALL_R8_ETMDATA_31;

pinMuxReg->PINMMR9 = ((~(pinMuxReg->PINMMR9 >> 18U) & 0x00000001U ) << 18U) | PINMUX_BALL_R9_ETMTRACECLKIN | PINMUX_BALL_W9_MIBSPI3NENA | PINMUX_BALL_V10_MIBSPI3NCS_0 | PINMUX_BALL_J3_MIBSPI1NCS_3;

pinMuxReg->PINMMR10 = PINMUX_BALL_N19_RMII_RX_ER | PINMUX_BALL_N15_ETMDATA_19 | PINMUX_BALL_N17_EMIF_nCS_0 | PINMUX_BALL_M15_ETMDATA_18;

pinMuxReg->PINMMR11 = PINMUX_BALL_K17_EMIF_nCS_3 | PINMUX_BALL_M17_EMIF_nCS_4 | PINMUX_BALL_L15_ETMDATA_17 | PINMUX_BALL_P1_RMII_RXD_0;

pinMuxReg->PINMMR12 = PINMUX_BALL_A14_RMII_RXD_1 | PINMUX_BALL_K15_ETMDATA_16 | PINMUX_BALL_G19_MIBSPI1NENA | PINMUX_BALL_H18_MIBSPI5NENA;

pinMuxReg->PINMMR13 = PINMUX_BALL_J18_RMII_TXD_0 | PINMUX_BALL_J19_RMII_TXD_1 | PINMUX_BALL_H19_RMII_TXEN | PINMUX_BALL_R2_MIBSPI1NCS_0;

pinMuxReg->PINMMR14 = PINMUX_BALL_E18_HET1_08 | PINMUX_BALL_K19_RMII_REFCLK | PINMUX_BALL_D17_EMIF_nWE | PINMUX_BALL_D16_EMIF_BA_1;

pinMuxReg->PINMMR15 = PINMUX_BALL_C17_EMIF_ADDR_21 | PINMUX_BALL_C16_EMIF_ADDR_20 | PINMUX_BALL_C15_EMIF_ADDR_19 | PINMUX_BALL_D15_EMIF_ADDR_18;

pinMuxReg->PINMMR16 = PINMUX_BALL_E13_ETMDATA_12 | PINMUX_BALL_C14_EMIF_ADDR_17 | PINMUX_BALL_D14_EMIF_ADDR_16 | PINMUX_BALL_E12_ETMDATA_13;

pinMuxReg->PINMMR17 = PINMUX_BALL_D19_HET1_10 | PINMUX_BALL_E11_ETMDATA_14 | PINMUX_BALL_B4_RMII_CRS_DV | PINMUX_BALL_E9_ETMDATA_08;

pinMuxReg->PINMMR18 = PINMUX_BALL_C13_EMIF_ADDR_15 | PINMUX_BALL_C12_EMIF_ADDR_14 | PINMUX_BALL_M2_GIOB_0;

pinMuxReg->PINMMR19 = PINMUX_BALL_E8_ETMDATA_09 | PINMUX_BALL_B11_HET1_30 | PINMUX_BALL_E10_ETMDATA_15 | PINMUX_BALL_E7_ETMDATA_10;

pinMuxReg->PINMMR20 = PINMUX_BALL_C11_EMIF_ADDR_13 | PINMUX_BALL_C10_EMIF_ADDR_12 | PINMUX_BALL_F3_MIBSPI1NCS_1 | PINMUX_BALL_C9_EMIF_ADDR_11;

pinMuxReg->PINMMR21 = PINMUX_BALL_D5_EMIF_ADDR_1 | PINMUX_BALL_C8_EMIF_ADDR_10 | PINMUX_BALL_C7_EMIF_ADDR_9;

pinMuxReg->PINMMR22 = PINMUX_BALL_D4_EMIF_ADDR_0 | PINMUX_BALL_C5_EMIF_ADDR_7 | PINMUX_BALL_C4_EMIF_ADDR_6 | PINMUX_BALL_E6_ETMDATA_11;

pinMuxReg->PINMMR23 = ((~(pinMuxReg->PINMMR5 >> 1U) & 0x00000001U ) << 8U) | ((~(pinMuxReg->PINMMR5 >> 9U) & 0x00000001U ) << 16U) | ((~(pinMuxReg->PINMMR5 >> 17U) & 0x00000001U ) << 24U) | PINMUX_BALL_C6_EMIF_ADDR_8;

pinMuxReg->PINMMR24 = ((~(pinMuxReg->PINMMR4 >> 17U) & 0x00000001U ) << 0U) | ((~(pinMuxReg->PINMMR4 >> 25U) & 0x00000001U ) << 8U) | ((~(pinMuxReg->PINMMR20 >> 17U) & 0x00000001U ) << 16U) | ((~(pinMuxReg->PINMMR8 >> 9U) & 0x00000001U ) << 24U);

/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
pinMuxReg->PINMMR25 = ((~(pinMuxReg->PINMMR12 >> 17U) & 0x00000001U ) << 8U) | ((~(pinMuxReg->PINMMR7 >> 9U) & 0x00000001U ) << 16U) | ((~(pinMuxReg->PINMMR0 >> 26U) & 0x00000001U ) << 24U);

/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
pinMuxReg->PINMMR26 = ((~(pinMuxReg->PINMMR0 >> 18U) & 0x00000001U ) << 0U) | ((~(pinMuxReg->PINMMR9 >> 10U) & 0x00000001U ) << 8U) | PINMUX_BALL_W6_MIBSPI5NCS_2 | PINMUX_BALL_T12_MIBSPI5NCS_3;

pinMuxReg->PINMMR27 = PINMUX_BALL_E19_MIBSPI5NCS_0 | PINMUX_BALL_B6_MIBSPI5NCS_1 | PINMUX_BALL_E16_MIBSPI5SIMO_1 | PINMUX_BALL_H17_MIBSPI5SIMO_2;

pinMuxReg->PINMMR28 = PINMUX_BALL_G17_MIBSPI5SIMO_3 | PINMUX_BALL_E17_MIBSPI5SOMI_1 | PINMUX_BALL_H16_MIBSPI5SOMI_2 | PINMUX_BALL_G16_MIBSPI5SOMI_3;

pinMuxReg->PINMMR29 = PINMUX_BALL_D3_SPI2NENA;

PINMUX_GATE_EMIF_CLK_ENABLE(OFF);
PINMUX_GIOB_DISABLE_HET2_ENABLE(OFF);
PINMUX_ALT_ADC_TRIGGER_SELECT(1);
PINMUX_ETHERNET_SELECT(RMII);

/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
PINMUX_SET(0,A5,GIOA_0);
PINMUX_SET(18,A11,HET1_14);
PINMUX_SET(3,B3,HET1_22);
PINMUX_SET(1,C2,GIOA_1);
PINMUX_SET(21,K2,GIOB_1);
/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
PINMUX_SET(0,W10,GIOB_3);

/* USER CODE BEGIN (3) */
/* USER CODE END */

/* Disable Pin Muxing */
kickerReg->KICKER0 = 0x00000000U;
kickerReg->KICKER1 = 0x00000000U;

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

steven Robalino said:

is there some connection between the MAC and MDIO that would nbot let it work without a PHY ?

or what are we missing?

Steve,

I think I mentioned this before but I'll try to be more specific.  If you look at 'hdkif.c' you will see MAC and PHY operations are interspersed inside 'hdkif_hw_init' for example.

So if you changed the PHY  (or substitute a switch for the DP83xxx phy ... same thing in this case) you probably are breaking this code and you will need to adapt it to do any MDIO configuration needed by your switch.

For example some code is very specific to the phy:

  while ((phyID == 0) && (phyIdReadCount > 0)) {
      phyID = Dp83640IDGet(hdkif->mdio_base, hdkif->phy_addr);
      phyIdReadCount--;
      sciDisplayText(sciREGx, txtProgress, sizeof(txtProgress));
  }

I believe if you dig into Dp83640IDGet you'll even find it returns 0 if it doesn't get an exact match to the DP83640's ID.

But if you are having an error in this area of code - you should be seeing logging on the SCI with error messages.

Did you fix any of this code for your new board and are you seeing any error messages logged?

Side note:  If you have a TI HDK for the 3137 I believe that this board can be modded to work in RMII mode.. I'll investigate as this may be something you could then begin with to get you a reference closer to your own custom hardware.

all the DP83640 code is bypassed - all we do is set the EMAC - the switch sets itself for RMII and 100Mbit

The EMAC configures itself properly - no errors

we try to send data using UDP and there is no data movement on TX pins - like the pin muxing is not working at all in RMII

again - is there some connection between the MAC and MDIO that would not let it work without a PHY ?

as you know the MDIO is continuosly checking for link from the phy (the MDIO bus is not connected in our case)

steven Robalino said:

again - is there some connection between the MAC and MDIO that would not let it work without a PHY ?

No.   The only connection is via the driver code and if you have bypassed this you might be ok. Unless inadvertently you commented out some last-minute MAC configuration that was delayed unitl some MDIO register read.   Setting the RMII speed of the MAC control register to match the link speed as reported over MDIO would be an example of this sort of deferred MAC configuration.

They are documented together only because they are a standard 'subsystem' across TI devices but otherwise they are separate modules.

then its got to be some issue with setting the pin muxing
we have checked every PINMMR register involved in the EMAC muxing and it matches your documentation
again we send a udp packet and no data comes out of the RMII pins of the TMS570

I don't see anything in the *source* that appears to be wrong or missing.
(w. regard to pinmux).

What would be best is to get a dump of the PINMMR registers that relate to EMAC.
Then we can check that the hex values resulting from the above source are:
a) correct (not #define mistake or some other mistake in translation)
b) overwritten by something embedded in the other code you are porting from

EDIT:  BTW you did validate that you see a 50MHz clock on the RMII Ref CLK pin, correct?

here are the registers - we see OK, can you double check
The cloxk has been proven to be 50mhz

PINMMR10 0x01010104 Pin Multiplexing Control Register 10 [Memory Mapped]
PINMMR11 0x08010101 Pin Multiplexing Control Register 11 [Memory Mapped]
PINMMR12 0x01020104 Pin Multiplexing Control Register 12 [Memory Mapped]
PINMMR13 0x02080808 Pin Multiplexing Control Register 13 [Memory Mapped]
PINMMR14 0x02010401 Pin Multiplexing Control Register 14 [Memory Mapped]
PINMMR15 0x01010101 Pin Multiplexing Control Register 15 [Memory Mapped]
PINMMR16 0x01010101 Pin Multiplexing Control Register 16 [Memory Mapped]
PINMMR17 0x01040101 Pin Multiplexing Control Register 17 [Memory Mapped]
PINMMR18 0x01010101 Pin Multiplexing Control Register 18 [Memory Mapped]
PINMMR19 0x01010101 Pin Multiplexing Control Register 19 [Memory Mapped]
PINMMR20 0x01010101 Pin Multiplexing Control Register 20 [Memory Mapped]
PINMMR21 0x01010102 Pin Multiplexing Control Register 21 [Memory Mapped]
PINMMR22 0x01040402 Pin Multiplexing Control Register 22 [Memory Mapped]
PINMMR23 0x01000004 Pin Multiplexing Control Register 23 [Memory Mapped]
PINMMR24 0x01010001 Pin Multiplexing Control Register 24 [Memory Mapped]
PINMMR25 0x01010000 Pin Multiplexing Control Register 25 [Memory Mapped]
PINMMR26 0x01010001 Pin Multiplexing Control Register 26 [Memory Mapped]
PINMMR27 0x01010101 Pin Multiplexing Control Register 27 [Memory Mapped]
PINMMR28 0x01010101 Pin Multiplexing Control Register 28 [Memory Mapped]
PINMMR29 0x01000102 Pin Multiplexing Control Register 29 [Memory Mapped]

should VCLKA4 be 40mhz or some other frequency? - we have it set for 40 currently

These look fine although I'm still looking for the bit that switches the MAC's gasket into RMII mode.
But the individual pinmux for the pins look fine.

-Anthony

You're feeding 50MHz from the switch into the MCU right? So VCLKA4 doesn't enter the picture and RMII_REFCLK should be an INPUT into the MCU.

If that's not the case please do let me know.

What is your VCLK3 frequency - I think there is a minimum requirement for this..

Hmm. Let me double check this. I see something in the TRM that says

"All internal EMAC logic is clocked synchronously on the VCLKA4 domain. Please refer to the
"Architecture" chapter of the technical reference manual for more details."

Although this doesn't match my understanding of how the device works; so suspect it's just a TRM error. Good question to raise.

There is also some minimum frequency to clock the EMAC v.s. the data rate but I can't remember if this is just tied to keeping the FIFO from overflowing or if it had actually to be faster than say the MII clock. I'll go dig that up.

we have vclkA3 set to 80mhz - and we are feeding 50mhz on pin K19
vclkA4 is 40mhz - please look at table 2-10 about VCLKA4....its not clear when TX and RX clock are internally generated

Steven,

So just to clarify, it is VCLK3 not VCLKA3 that is 80MHz..?

K19 is: N2HET1[28]/MII_RX_CLK/RMII_REFCLK/MII_RX_AVCLK4

My understanding is:
1) in RMII mode, the MAC always treats RMII_REFCLK as an input.

2) at the device level you have the pinmux above, which allows you to source the 50MHz from the on-chip PLL by selecting MII_RX_AVCLK4.

in this case the pin K19 becomes an output and AVCLK4 appears on the pin.

one nuance of the pinmux is that the *input* signal from the pin goes to all pins in the list,
so you can still 'observe' that clock through N2HET1[28] or through RMII_REFCLK.

3) So you've got two different use cases:

a) phy or external oscillator drives 50MHz into ball K19.
select RMII_REFCLK in the pinmux.
**** this should be your use case from your pinmux and statement above ****

b) for some reason like saving $$ on a separate crystal you decide to use the on chip PLL to source 50MHz .. which is OK.
- select MII_RX_AVCLK4 in pinmux.
- AVCLK4 frequency is driven onto the ball K19.
- from MAC perspective, it cannot tell the difference between this clock source and one
coming from an external phy... it uses this AVCLK4 for the RMII interface.

I think that the statement in the TRM is wrong and that in your use case (a) AVCLK4 is irrelevant but I'm asking one of my colleagues to confirm this.

Also if your VCLK3 is 80MHz than you should be good. If it were 40Mhz then I might be concerned about another limitation like internal clock > line rate.. but 80MHz is fine.

I really don't think there's any issue w. the clock settings here. But will confirm that odd statement about AVCLK4 is false. It may take some time though and I think it's not smart to assume the problem is here; it's almost certainly somewhere else.

BTW - You still have your 3137 HDK correct?

We *should* be able to add a pullup resistor to a DNP location on the HDK and make it work in RMII mode.
That'll take a bit of time and I won't be able to do it this week but short of you getting a CNCD .. this would at least give you something to compare apples to apples against...

I know RMII has been used on the HDK before but we ship the kit configured for MII (long story and multiple reasons why) but it shouldn't be difficult to do a similar MII->RMII swap on the lwIP example and on the hardware and get you working on the HDK in RMII mode..

Ok I was looking again for that PINMMR29[24] which is documented as GMII_SEL and is why it wasn't coming up on a search for RMII. But your register dump shows it set to '1' for RMII mode so that is good.

So basically doesn't seem like there are any issues in the pinmux or device clocking.

as mentioned before the MAC does not respond to interrupts or outputs data- like its not enabled in RMII mode - it looks to me that RMII is not really operational in the TMS570ls3137.

We need TI to tell us what to do next - we have spent over a week on this issue

Steven,

I think you should work on a different aspect of your system until we send you instructions for the HDK in RMII mode. Then we'll have a common platform and one on which you can test your own code build.

I'm quite sure the TMS570LS3137 EMAC works in RMII mode; although I can understand why you would be skeptical. At his point I don't think you should spend any more time and get yourself any more frustrated.

are you going to est the HDK changes before you send it to us?

of course, and take pictures of what you need to mod. this is why it's going to take a while.

....I meant to TEST the change before we do it

So now I don't understand what you mean by TEST..

But, I'm going to do exactly this:
1) take stock HDK TMS570LS3137 HDK and build the lwIP example project for MII mode. (as is)
2) run the example to confirm it works.
3) copy the example to an "RMII" folder
4) modify the copy to run in RMII mode
5) modify the HDK board to run in RMII mode
6) photo the mods so you can make the same
7) run the example / confirm it works
8) zip it all up and attach to this thread

Steven,

So reviewing some things - I see this:

"we have checked the MAC registers - specifically MACCONTROL is set to 0x8001, the interrupt registers are enabled and the MAC chip is in IDLE"

So, you've got the MAC in Reset?

when you enable RMII only in halcogen it adds this function to emac.c

void EMACMIIDisable(uint32 emacBase)
/*SAFETYMCUSW 1 J MR:14.1 <APPROVED> "LDRA Tool issue." */
{
HWREG(emacBase + EMAC_MACCONTROL) &= (~(uint32)EMAC_MACCONTROL_GMIIEN);
}

if you enable MII it adds this function instead

void EMACMIIEnable(uint32 emacBase)
{
HWREG(emacBase + EMAC_MACCONTROL) |= EMAC_MACCONTROL_GMIIEN;
}

the comment may help you to understand...
**
* \brief This API disables the MII module and holds MII Rx and Tx in reset.
*
* \param emacBase Base address of the EMAC Module registers.
*
* \return None
*
void EMACMIIDisable(uint32 emacBase)

Yes this feels like a bug. This is what the internal design spec says about that bit.

"gmii_en GMII Enable –
0 – GMII RX and TX disabled (state machine reset).
1 – GMII RX and TX enabled for receive and transmit. "

I think something may be lost in translation between this and our TRM.

The MAC is actually a subset of a gigabit mac and it's got a "GMII" output.
(subset = smaller buffer/lower cost and can't keep up w. Gigabit rates).

In between the GMII output of the MAC and the pins there is what is called a 'gasket' that
converts GMII to either MII or RMII but if GMII is disabled nothings going to go in or come out..

So you need to flip this bit. GMII needs to be enabled.

I think that it's the checkbox on the EMAC tab that's mislabeled as "MII Enable" that is controlling this

'GMII_EN' bit.

I flipped it and did a diff on the output and the pinmux.c file output still stayed in RMII mode but now

the GMII_EN bit would be set ..

Please try that and confirm.  If it's the issue then I'll make sure i get a ticket filed on this so it is clarified..  and also get the TRM chapter updated.

-Anthony

e2e.ti.com/.../302253

e2e.ti.com/.../303911

IP Reuse.

Steven,

So I submitted two tickets

SDOCM00122622- for the TRM w. a proposed clarification. It is clear now that GMII_EN does not select between RMII and MII mode. Had some internal discussions about other device TRMs as well..

SDOCM00122625- for HalCoGen. The checkbox should be removed.
In the function uint32 EMACHWInit(uint8_t macaddr[6U]), the procedure for initializing the MAC as documented
in SPNU499B 29.2.16.4 EMAC Module Initialization is not being followed correctly because of this confusion.

Instead early in EMACHWInit (in 'step 2') EMACMIIDisable(hdkif->emac_base); should be called unconditionally.

Then late in EMACHWInit (in 'step 16') EMACMIIEnable(hdkif->emac_base); should be called unconditionally.

Try that modification later after just flipping the state of the bit. I'd flip the state of the bit in the header file first though because it's a less intrusive modification and it is known to work at least in MII mode.

-Anthony