TMS320F28388D: F28388D - NDK - DP83826E

Elker ,

Your query will be forwarded to an PHY expert, please expect a response in a couple of days.

Best Regards

Siddharth

Elker,

Are you still using the DP83822 drivers? If so, please utilize the DP83826 drivers, which I have linked the product page (https://www.ti.com/product/DP83826E#software-development)

Furthermore, if that does not resolve the issue, could you send 0 through 1e registers and also the strap registers?

Sincerely,

Jason Lee

Hello Jason,
thanks for the reply. The page you are pointing links to the linux kernel driver which has the same driver for DP83822 and DP83826E (file is drivers/net/phy/dp83822.c).

The only NDK EMAC driver for F28388D that I'm aware of is the ndk_f2838x_3_61_01_01, linked here:
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/825398/tms320f28388d-tcp-ip-stack-availability

Inside this driver source code there is no reference to phy model and the only access to phy register is for detecting link (which works) and for reading and clearing interrupt status register (that seems to work for recv messages).

I will dump register for dp83822 and dp83826 and check if there are any differences.

About straps, we are using dp83826 in basic mode so there are no external configurations via pullup/down; I don't expect issues here.

Please let me know about any difference in configuration for DP83822 and DP83826E.

Best regards,
Elker 

Elker,

Yes, at earliest convenience, please send over registers so that we can investigate. Thanks!

Sincerely,

Jason Lee

Hello Jason,
here you are the comparison between PHYs registers:

the only relevant changes are PHYIDR2 (which matches datasheet for both components) and CR3 (which is at default for DP83822 while on DP83826E is reserved); all register seems at default value, which is coherent with NDK driver that does not change anything on boot.

If it helps, I can dump more registers.

Best regards,
Elker

Elker,

Could you try a soft reset (writing 4000 to Register 0x1F) and let me know if the issues persist? 

Sincerely,

Jason Lee

Hi Jason,

I received the following from the customer directly and have attached.  Can you take a look please?

Thanks,

Tom

Elker thread 1180359.docx

Hello Jason,
I've implemented the register write and written register 0x1F with device reset (mask 0x4000).
Phy link led switches off and after few second comes back on, as expected; this behavior is seen also in variable emacData.linkUp.
When pinging from pc, I can see emacData.rxCount counting on each poll, but nothing on the tx side (same as described in the first post of the thread).

Also analyzing the Linux driver for DP83822 and DP83826E I cannot see any difference in the configuration: it should work with default configuration; please let me know is this assumption is true for DP83826E.

Best regards,
Elker

Elker,

I will consult with the team and get back to you shortly.

Sincerely,

Jason Lee

Elker and Tom,

Since this thread has been ongoing for quite some time now, could you two summarize the most recent issues you and your team are having? Our Applications team is slightly lost with the amount of variables in this query.

In the meantime, I met with our team and we suggest the following: Check link-up, then RJ45 cable connection, then magnetics. Just a heads up, the connector schematics are in fact different from DP83822 and also DP83826. Furthermore, I have attached a schematic checklist (Software Drivers can be found on DP83826's product page on ti.com)

DP83826_Schematic_Design_Review_Checklist.xlsx

Sincerely,

Jason Lee

Hi Jason,

I drew the board that Elker is working on.

about the checklist... I put some notes about the hardware. Can you check my notes?

DP83826_Schematic_Design_Review_Checklist_Paolo.xlsx

"Since this thread has been ongoing for quite some time now, could you two summarize the most recent issues you and your team are having? Our Applications team is slightly lost with the amount of variables in this query."

Basically what Elker sees is: When pinging from pc, emacData.rxCount counting on each poll, but nothing on the tx side

Thanks,
Paolo

Paolo,

I will check these schematic notes and also bring this to the team; Thank you for your patience.

Sincerely,

Jason Lee

Works !!!

I realized that in order to get a response from the ping command it was necessary to change this setting on my network card.

I had to remove the "Auto Negotiation" setting and put "10 Mbps Full Duplex".

This was not necessary with the PHY DP83822.

How come?
Do we need to set up any registry?

Hello Paolo,

Jason will have a look at this feedback when he returns back to office tomorrow (today is holiday in TI, US). But just to understand it a little further :

- My basic understanding is that 822 worked fine in their system and 826 is not linking up in 100Mbps mode when autoneg is on with link partner. Is that correct?

- Regarding the register snapshots shared in the previous post, were they captured when respective 822 and 826 were connected to PC : 

          I dont see either of them linking up (register 1)+ neither of them are receiving any speed status from link-partner (register 5 and 6)

- Please share the register value of x467 and x468 of 826. It will help us confirm whether the PHY is booting up in required strap mode.

- If they force 100Mbps Full-duplex from their PC (instead of autoneg), does 826 again link-up? This will help us ascertain whether the problem is with auto neg or 100Mbps link-up.

--

Regards,

Vikram

1) "- My basic understanding is that 822 worked fine in their system and 826 is not linking up in 100Mbps mode when autoneg is on with link partner. Is that correct?" 

Correct !

4) "- If they force 100Mbps Full-duplex from their PC (instead of autoneg), does 826 again link-up?"

No! Setting the PC to 100 Mbps the 826 won't connect!

For points 2 and 3 I await answers from Elker

Paolo,

Thank you for the feedback! We will wait for Elker's response and continue further investigation.

Sincerely,

Jason Lee

Hello Jason,
sorry for my late reply.

I've implemented extended register reading for clause 22 phy and finally read registers 0x467/0x468.
Here the comparison between DP83822 and DP83826E with pc connected (e.g. link up).

I've double checked register 0x467 value (SOR1) and I find it with a strange 0x87 value; clause 22 reading seems correct since on DP83822 I can read values coherently with datasheet and also register 0x468 (SOR1) on DP83826E seems coherent with datasheet.

I've tried several power cycles but SOR1 for DP83826E reads always as 0x87; can this be a symptom of malfunction?

Best regards,
Elker

Elker,

Jason is out today and should get back to you early next week.

--

Regards,

Vikram

Elker,

Jason is still out but we had a review internally and following are the next steps that we can  try to resolve this : 

1. Can we take the dump of register with link-partner connected (we think that data log shared above is without link partner connected/linked-up) :

              a. With pc card programmed to auto-neg on 

              b. With pc card programmed to 10Mbps mode

2. Can we connect two of the boards with 826, see if it links up and capture the above register log in linked up case.

--

Regards,

Vikram

Hello Vikram,

I'm attaching the phy register dumps in these cases:
- pc card with auto-negotiation
- pc card with fixed speed @10MBps full duplex
- dp83826>>dp83826 with patch cable
- dp83826>>dp83826 with cross cable

2023_02_06-phy_compar3.xlsx

Please note: as our application implements a tcp server, in the board to board connection we can only check link detection and register dump; in particular link is detected in board to board connection.

In the file we highlighted the differences in various cases.

Is it possible to force 10MBps full duplex on PHY configuration at dsp boot? It would be acceptable for us to hardcode phy speed @10mbps; if possible, can you point which register/value to write? 

Best regards,
Elker

Elker,

In the xls I only see 822's sheet. Did you miss adding 826's status?

--

Regards,

Vikram

Hello Vikram,
please forgive my mistake.
The register dump contained in the attached xls are indeed done with 826 boards.

Best regards,
Elker

Hello Elker,

Oh ok then things are looking health on the PHY side : 

1. Register 1 for "pc autoneg on" shows that PHY is linked up fine. 

2. Register x10 for "pc autoneg on" shows that PHY is indeed linked up in 100Mbps mode.

Maybe we should look at the processor side to check if settings are ok to respond to 100Mbps data. Looping in Siddharth and we will take it from there.

Siddharth,

Looks like from PHY side data is coming in fine but MAC is not responding to ping request when linked in 100Mbps mode through autoneg. Does processor need anything set to support this?

--

Regards,

Vikram

Hi, 

What are the configurations done on the NDK side?  Specifically ,is there any configuration done for linkSpeed and linkMode? 

Best Regards

Siddharth

Hello Siddartah,
the NDK is configured by the ndk_f2838x_3_61_01_01.zip driver; in particular the files EMACF2838X.c and ethernet.c found in the driver are used in our project. The function EMACF2838XLLD_getInitConfig() is where the configuration structure is populated, in particular:

    configPtr->linkMode = ETHERNET_MAC_CONFIGURATION_DM_FULL_DUPLEX;

while linkSpeed is not assigned (and left to zero).

Do DP83826E require a different setting?

Regards,
Elker

Elker,

I also had a look at the source code for NDK TI drivers and observed that there are two parameters "linkSpeed" and "linkMode" in the structure EMACF2838XLLD_InitConfig in ethernet.h . The function EMACF2838XLLD_getInitConfig is used to configure this structure. Howver only the linkMode parmeter is configured to "ETHERNET_MAC_CONFIGURATION_DM_FULL_DUPLEX" in the EMACF2838XLLD_getInitConfig function of ethernet.c . I could not find any initialization done for linkSpeed and looks like it is not configurigng the speed. Unfortunately the team who was handling the NDK  it earlier is dissolved since NDK product is no longer supported. 

Best Regards

Siddharth

Elker,

Few other suggestions that might help you in narrowing down on the issue.

1.  Checking bit 14 (FES) of the MAC_Configuration register of EMAC .  This bit should be set to 1 for 100MBps configuration

2. You can try a simple loopback example between the MAC and the PHY to make sure that it is working.  There is an example provided within C2000Ware (ethernet_ex1_basic_tx_rx_loopback)  wihch can be used as reference. This example is based on the low level ethernet drivers and is validated on the Conrol Card (TMDSCNCD28388D) . There will be some changes required in the example based on your test setup . 

Best Regards

Siddharth 

Hello Siddharth,

Bit 14 of MAC_Configuration (FES) is 0.

The MAC_Configuration register is 0x0800_A003 which, in particular for bit 15/14 means port selected as 10MBps.
This configuration is same on DP83822 and DP83826E boards but DP83822 negotiates correctly with PC, while DP83826E no.

I will get you back for the "ethernet_ex1_basic_tx_rx_loopback" running on our board.

Regards,
Elker

Hello Siddharth,

I've loaded on TMDSCNCD28388D the "cm_common_config_c28x" with ETHERNET enabled and "ethernet_ex1_basic_tx_rx_loopback": without cable I get stats.rxUnicastPacketsGood=0 (fail) while if I plug ethernet cable to PC, the result is stats.rxUnicastPacketsGood=1 (success).

I've then configured our board pinout with DP83826E and repeated test on our board: I get same result as EVB, stats.rxUnicastPacketsGood=0 without cable and stats.rxUnicastPacketsGood=1 with cable connected.

From this test the DP83826E seems working correctly: as far as I understand, the ENET peripheral is communicating correctly with PHY.

Regards,
Elker

Elker, 

Pls check if the PHY loopback was enabled when you ran this example . You can read the PHY registers and verify it. 

If MAC and PHY are able to communicate , I am not sure what else  could be causing this issue.

Best Regards

Siddharth