TMS320C6678: Problem in Ehternet initialization on custom board

Alberto Chessa

Part Number: TMS320C6678

Hi,

I have a problem in the initialization of the Ethernet on a custom board based on C6678 and Marvel PHY.. During the initialization I have to insert long delay between subsystems initialization and anyway at the end the CPSW_CONTROL_REG and SGMII MR_ADV_ABILITY_REG seems to lost the correct initialization value. If I reinit only these two registers, the ETH start working.

Exactly the same SW works well on the C6678 EVM (but without the PHY init and with the parameters setup in accordance with the SGMII and Core clock frequency).

I cannot exclude at 100% a SW bug, but since on the EVM everything works, the is something I can check in our board design to investigate the problem? Maybe clocks, power supply...

The initialization steps are:

1. Configure the PHY (but on the EVM)

2. Configure SERDES

3. Configure SGMII ports

4. Configure the CPSW (ports enable, mac addresses)

5. Configure the ALE (enabled but bypass)

6. Configure the MACs (full duplex, giga, MTU)

7. HOTFIX: wait a bit and then check for "hot fix".

On the EVM:

- no delay required between steps

- HOT fix not required

On the custom board:

- delay required (5000 cycles @ 1GHz)

- HOT fix REQUIRED

On the custom board in debug, both step by step or breaking between step:

-delay not required

- HOT fix not always required

The HOTFIX procedure is simple:

1. verify the CPSW_CONTROL_REG.port 0 == enabled. If it is not not enable it.

2. if SGMII MR_ADV_ABILITY_REG == 0 then fix it with the correct value (the same used in the configuration step 3).

I already tried to play a bit with initialization order, but nothing changes. Also on the custom board I tried to skip PHY initialization. In this case the cable communication is not possible, but the loop-back tests are applicable and without the hotfix fails.

As test, I tried all level of loop-back:

PKTDMA (PA)
SGMII
MAC
PHY

They fail (except for the DMA) without the fix (while works always on the EVM),

This the POST SW from TI (modified in accordance with the board clocks), also the PKTDMA PA loop-back fail and I was not able to fix it.

That's why, to investigate the problem, I rewrite from scratch the initialization code (bypassing the PA PDSP and routing directly the RX channels to the PKTDMA)

over 6 years ago

0 Yordan Kovachev over 6 years ago

TI__Guru**** 161600 points

Hi,

I've notified the software team. Their feedback will be posted here.

Best Regards,
Yordan

0 lding over 6 years ago in reply to Yordan Kovachev

TI__Guru* 95265 points

Hi,

TI 6678EVM used Marvell 88E1111 PHY, does your board use the same PHY or different? It looks the code execution timing made difference on your board vs EVM (cycle delay, step through/break point).

The 6678EVM doesn't have step 1. On your board, if you do step 1 followed by much longer delay and remove all the delays from step 2 to 6. Do you need the hot fix?

In the code step through case, are you able to see at which step CPSW_CONTROL_REG and SGMII MR_ADV_ABILITY_REG loss the intialization value? Or they never loss so the port worked? What are the values: 1) before step 3 2) after step3 and 3) in step 7 before re-intialization?

Regards, Eric

0 Alberto Chessa over 6 years ago in reply to lding

Mastermind 6650 points

PHY: We use an88E1512 but it is not related to the problem since:
- If I don't configure it (it start as RGMII) or I keep it in power-down, the results doesn't change (well, only loop-back tests applicable)
- on EVM Port 0 there is not phy connected since I suppose it is similar to my board port 0 with PHY not configured

SGMII MR_ADV_ABILITY_REG config lost: without delay on port 0 it seems to appears immediately after the configuration, while port 1 seems to keep the correct value (configured in sequence in a for 0..1 loop). With delay it is after ALE config.

CPSW_CONTROL_REG config lost: after ALE config, there is jus on the step that follow its initialization.

Note that the previous observation are only indicative since every "perturbation" in the sequence seems to "move" the point that generate the problem.

On the EVM, the same instrumentation produce always the corrected results, that is it seems there is not an bug. To access the devices I don't use only the structures and addresses defined in the CSL. I suppose that an hidden bug that generate wrong write on the devices should be reproducible on the EVM also.

0 Tom Johnson 16214 over 6 years ago in reply to Alberto Chessa

TI__Mastermind 46460 points

Alberto,

The value stored in the SGMII MR_ADV_ABILITY_REG should not spontaneously clear. I expect there is something causing this issue - either hardware or software. Does the identical software run ion the EVM? There is possibility that the code on the custom board has a software error that is overwriting this MAC configuration.

Alternately, is there the possibility of a power supply issue? Values get cleared when the power glitches. Please double-check the power and clock sequencing and make sure that the supplies are stable and that they remain stable during boot. You might also check your layout for isolated power or ground islands or areas where the planes are narrow resulting in current starvation.

The 88E1512 is used on some of our KeyStone-II EVMs. The MAC implemented in the C6678 should not have any problem working with this PHY.

Tom

0 Alberto Chessa over 6 years ago in reply to Tom Johnson 16214

Mastermind 6650 points

Hi,

I consider the possibility of a SW bug, but:
- same SW on EVM works fine, without any delay and hotfix, both on port 0 (not connect to a phy, only loopback test applicable) and on port 1 (loopback and ping test ok)
- execution step by step everything ok on the custom board (in the tests project all interrupt are disable, there is not kernel so I exclude race conditions)

I forward you comments to the HW design team to see if it possible to perform some verification.

Processors

Processors forum

TMS320C6678: Problem in Ehternet initialization on custom board