TMS320C6657: C66EMAC loopback test passed but NIMU_emacExample failed.

David Trinh

Part Number: TMS320C6657

Dear,

I am writing to ask about a board bring up problem regarding the Ethernet port on the C6657.

I have a CUS board with C6657 and 88E1112 PHY, the schematic is identical with that on the EVM. Currently, all needed HW are working flawlessly except the Ethernet port. I used the EMAC_evmc6657_C66Loopback example to test both the EVM (in no boot mode) and my CUS board with identical results. ALL GOOD, packets go to HUB and comeback fine on both boards.

However, when I try the NIMU_emacExample_EVM6657C66BiosExample example. The project works good ON THE EVM (in no boot mode) and I could send and receive UDP packets over the network to my PC (using the NDK's provided winapp). Then, without changing anything, I run this same project on our CUS board but I failed to send or receive anything. (both boards use same evmc6657l.gel file )

I have checked and compared HW's behaviors on both boards and no difference has been noticed so far except the status LED on the ethernet port is blinking (Activity) on EVM while sending/receiving packet and SOLID ON (No activity) on my CUS board while the PC is sending out UDP packet to the CUS board.

Seems to me that the board can't talk to the outside world except itself.

Could you please advice me where and what to check to bring up the network, please?!

Thank you!

David

over 7 years ago

0 lding over 7 years ago

TI__Guru* 95265 points

Hi,

When you run the EMAC_evmc6657_C66Loopback example, it is switch level loopback from the user guide: software-dl.ti.com/.../Device_Drivers.html

I think you missed something to configure the PHY through the MDIO interface. In the NIMU case when talk to the real world, the driver code is pdk_c665x_2_0_x\packages\ti\transport\ndk\nimu\src\v0\nium_eth.c. Where we have open_cfg.phy_addr = 0x18;

Do you have the PHY at this address?

Regards, Eric

0 David Trinh over 7 years ago in reply to lding

Intellectual 290 points

Dear Eric,

Thank you for your reply.

As I said in previous post, schematic for the Ethernet is copied exactly same as that on the C6657 EVM. PHY same and PHY address same.

When the NIMU was not working, I check signal on the MDIO pins working fine and tracked back to the nimu_eth.c file as you said, how ever 0x18 is the address both EVM and by CUS board are using but the HW is still not working.

Today, I will try to check read/write PHY registers to make sure that the driver is talking correctly with the PHY. In the meantime, if you have any new ideas, please let me know.

Thank you again.

David

0 David Trinh over 7 years ago in reply to David Trinh

Intellectual 290 points

Dear Eric,
I have checked read/write to the PHY register on my CUS board at address 0x18 and everything is fine. I think the addressing issue can be skipped here.
Thanks again.
David

0 David Trinh over 7 years ago in reply to David Trinh

Intellectual 290 points

Dear Eric,

Hello again,

I am adding here all the reg values read out from the PHY chip for your reference.

CTRL 0 val: 0x1140
CTRL 1 val: 0x796d
CTRL 2 val: 0x141
CTRL 3 val: 0xc97
CTRL 4 val: 0x1e1
CTRL 5 val: 0x45e1
CTRL 6 val: 0x7
CTRL 7 val: 0x2801
CTRL 8 val: 0x0
CTRL 9 val: 0xf00
CTRL 10 val: 0x4000
CTRL 11 val: 0x0
CTRL 12 val: 0x0
CTRL 13 val: 0x0
CTRL 14 val: 0x0
CTRL 15 val: 0xf000
CTRL 16 val: 0x6060
CTRL 17 val: 0x7c4a
CTRL 18 val: 0x0
CTRL 19 val: 0x1c52
CTRL 20 val: 0x0
CTRL 21 val: 0x0
CTRL 22 val: 0x8000
CTRL 23 val: 0x0
CTRL 24 val: 0x0
CTRL 25 val: 0x0
CTRL 26 val: 0x40

TCP/IP Stack 'Hello World!' Application

Service Status: DHCPC : Enabled : : 000
Service Status: DHCPC : Enabled : Running : 000
Service Status: DHCPC : Enabled : Fault : 002

Thank you!

0 lding over 7 years ago in reply to David Trinh

TI__Guru* 95265 points

Hi,

Please refer to: www.ti.com/.../spruhh1.pdf

You may check the working EVM and failure one for the below modules to determine which path is broken, by using CCS memory window to check some status registers:

SERDES:
6.2 SGMII SerDes Status Register (SGMII_SERDES_STS)

MDIO:
5.4 PHY Acknowledge Status Register (ALIVE)
5.5 PHY Link Status Register (LINK)

SGMII:
7.5 Status Register (STATUS)

EMAC: chapter 8, for those statistic registers. Does the Ethernet port receive any packets?

Regards, Eric

0 David Trinh over 7 years ago in reply to lding

Intellectual 290 points

Dear Eric,

Thanks again for the informative guide.

I have check all related registers and results are as follow:

1. MDIO link and registers working identical on both boards when cable plug/unplug -> link up/link down accordingly

2. But, ONLY the SGMII link on the EVM board is functioning correctly according datasheets and application notes. However,by looking at the register as you advised, I found that my CUS board never can make a SGMII link up or auto negotiation (even thought the PLL is reported locked). I checked SGMII serdes signal activity on the EVM board and I can see activities back and forth between the DSP and the PHY chip accordingly when I run the NIMU project, even when the cable is unplugged, running the project also make the signal activities exist and link is up with negotiation fail. This is completely normal. However, my CUS board does not have the DSP SGMII's serdes TX signal activity exist yet and obviously EMAC buffer has nothing exept 0xFFFF.

I have tried many different things and still cannot see the signal activity from the DSP. I may be wrong but I am having the feeling that the DSP SGMII hardware on my CUS board is not doing anything meaningful at the moment.

Please advise me what to do next.

Thank you!

David

0 lding over 7 years ago in reply to David Trinh

TI__Guru* 95265 points

Hi,

Thanks for narrowing down the issue. For the SGMII serdes, we have setup by GEL: \ccsv8\ccs_base\emulation\boards\evmc6657l\gel:

#define SGMII_SERDES_STS (*(unsigned int*)(CHIP_LEVEL_REG + 0x158))
#define SGMII_SERDES_CFGPLL (*(unsigned int*)(CHIP_LEVEL_REG + 0x340))
#define SGMII_SERDES_CFGRX0 (*(unsigned int*)(CHIP_LEVEL_REG + 0x344))
#define SGMII_SERDES_CFGTX0 (*(unsigned int*)(CHIP_LEVEL_REG + 0x348))

function configSGMIISerdes().

Can you check your CUS board? Is the same routine used and the same value programmed? TI 6657 EVM SGMII reference clock is 250MHz, is the same on your board design? You mentioned that PLL locked. Do you see any error (e.g signal detection loss) in SGMII_SERDES_STS?

In the chapter 7, there are a few more registers to control the SGMII master/slave, forced linked or auto-negotiation (besides the 7.5 Status Register (STATUS) I mentioned earlier). Since you know STATUS showed failure, can you compare the difference between TI EVM and CUS board for the:

0x04 SOFT_RESET Soft Reset Register Section 7.3
0x08-0x0C - Reserved
0x10 CONTROL Control Register Section 7.4
0x14 STATUS Status Register (read only) Section 7.5
0x18 MR_ADV_ABILITY Advertised Ability Register Section 7.6
0x1C - Reserved
0x20 MR_LP_ADV_ABILITY Link Partner Advertised Ability Section 7.7

And I assume you just use the TI NIMU test example without changing it? The TI C6657 MAC is the slave with auto-negotiation and PHY side is the master.

I am not quite familiar with PHY side setting. Is there something to enable master mode and auto-negotiation? Are you able to read out the EVM PHY registers and compared with CUS you dumped earlier?

Regards, Eric

0 David Trinh over 7 years ago in reply to lding

Intellectual 290 points

Dear Eric,

Thank you for your excellent supports to walk me though this problem.

We finally got the board work the way it is supposed to. The problem lies with the CUS board's HW which is different from the EVM.

Keep up the excellent works and have a nice new week.

Regards,

David

Processors

Processors forum

TMS320C6657: C66EMAC loopback test passed but NIMU_emacExample failed.