DP83849I: Exterder Mode LWIP Stack Programming Hierarchy with Single MAC

Hi Volkan!

I read through your message, as well as your previous post here. I want to take a step back and start the discussion from a high level and slowly work our way down into the details. Below I have summarized my understanding of your end use application, please correct me if I misunderstood.

MAC A is connected and MAC B is left floating. 

In Normal Mode, Data flow would be from MAC A to Port A . You have confirmed that this case is working in your application.

In Extender Mode, Data Flow would be from Port A to Port B, completely bypassing the MAC interface

From what I understand, you want to switch between Normal and Extender mode based on the destination address of the ethernet packet. I do not think there is an easy way to accomplish this. For example, if we are in Extender Mode, no packets will ever be received on MAC A, meaning the MCU will never receive any data to make the decision on when to tell the 849 to switch modes.

As a quick experiment to confirm this, could you

1. Configure the 849 Dev Kit board into Extender Mode
2. Confirm that extender mode is working as expected, i.e. traffic sent into Port A comes out of Port B (and vice versa)
3. After extender mode is confirmed working, probe the RX_D[1..0] lines of MAC A to see if any activity can be seen
   1. From the Cable Extender Section of the AN-1509 App note we can see the figure below, where a note mentions that the MAC interface is unused.
      1. 

Regards,

Alvaro

Hi Alvaro !
Thank you for your quick reply with valuable comments and suggestions. I would be pleased to share the details of the project and progress step by step. I will try to explain the application as simple as possible.
As you stated in your post, the MAC-A of the PHY is directly connected to the MAC of the MCU via the RMII interface. MAC B is left floating.

Any thoughts and recommendation i appriciate
Best Regards
Volkan

Hi Volkan,

Thank you for the block diagram, it was very helpful. The current configuration would not be possible for the reason I mentioned below.

Alvaro (Al-vuh-roe) Reyes said:

For example, if we are in Extender Mode, no packets will ever be received on MAC A, meaning the MCU will never receive any data to make the decision on when to tell the 849 to switch modes.

A solution would be to use both MACs, A & B, and both Ports, A & B. This would essentially be the same as having two ethernet PHYs on your board.

Regards,

Alvaro

Hi Alvaro,
I am shocked to learn that the project I have been working on for 7 months is trash.

Alvaro (Al-vuh-roe) Reyes said:

For example, if we are in Extender Mode, no packets will ever be received on MAC A, meaning the MCU will never receive any data to make the decision on when to tell the 849 to switch modes.

Regarding to your final comment i am a little bit confused and Some questions need to be clarified.
Regards
Volkan

Hi Volkan,

Thank you for you response, I want to apologize because I have mislead you. Yes, the RX Monitoring feature will allow MAC A to see the packets being received from Port A. Please see my response (1-3) below for more details.

1. After reading this post, I believe there were several miscommunications. The biggest of which is the following:
   1. "Regarding to this implementing If I want to connect only MAC-A' s (or only MAC-B's ) RX and TX pins via RMII interface, This mean I can able to communicate with both PHY-A and PHY-B ports as transmitter and receiver of Dual PHY at the same time ? (some delays may ignored)"
      1. This is not true. MAC A can be configured for Port A or Port B, but MAC A cannot communicate through both Port A & B at the same time.
         
         1. With the exception of Broadcast Transmit, where a single MAC can transmit to both ports
            1. But a single MAC cannot receive from both ports at the same time
2. Using snla086b.pdf as reference:
   1. Extender mode does not include the MAC interface, as shown in in Figure 6
      
      1. 
   2. However you are correct, Section 3.4.1.1 in the app note mentions that RX monitoring is enabled by default if strapped into Extender Mode and can be enabled by setting RBR Register 0x17[12:11] = 00
      1. I apologize for the misunderstanding, this will allow your application to function.
3. This is an excellent question, and I apologize for misleading you. Your understanding was correct
   1. The only difference between the Normal Port and Extender Port, is that the TX MAC line (i.e. the output from the MCU to the PHY) is not active
      1. referred to as RX Monitoring
         1. Again, I apologize for the confusion, this would allow your application to function.

User4699 said:

As i stated previously, It is aimed to provide data flow to many nodes have different ip addresses in the same network, By dynamically configured to mux as its Extender and Normal Port Mode of the PHY's Registers.
PHY will wait extender mode until matched destination address of the ethernet packet received, If response required then change its mode as Normal to establish Mac-A to Port-A TX pin active.

In theory this is possible, but this seems like a much more difficult implementation of a daisy chain. Is your MCU limited on the amount of available MAC interfaces? 

Your current issue lies within this RX monitoring function. How exactly is this being implemented? My understanding is described below

1. Node 1 is in Extender Mode with RX Monitoring enabled
2. Node 1 received a packet that requires a response back to the Host PC
   1. The MCU would need to write to the 849 registers to configure it to Normal Port mode
   2. During this time, the Host PC will not be able to send packets downstream of Node 1
   3. The MCU will send the response to the Host PC, then configure the DP83849 back into Extender Mode with RX Monitoring

What would happen if the Host PC tried to ping Node 1?

Regards,

Alvaro

Hi Alvaro
First of all, thank you for the answer I've been looking forward to reply from you :) Yes, I asked this question 7 months ago because I did not know the exact details of PHY.  Anyway I need your help and support to get this PHY working properly.
Best Regards
Volkan

Hi Volkan,

In your current configuration, does your set up work with a ping command? I.e. will the node recognize that the packet is addressed to it and change the 849 into extended mode? 

Is the issue specifically only when sending UDP packets?

Regards,

Alvaro

Hi Alvaro !
I performed the tests with the same configuration settings.
 in the same configuration settings, MDIX MODE is 1 when starting in Normal mode, while MDIX MODE is 0 when starting in Extender mode. Can this affect it?
Best Regards
Volkan

Hi Volkan,

Keeping the debug focused on the hardware for now, could you compare the signals on the RX_Data lines between Normal mode and Extender Mode? Does the data look the same?

This is to confirm if the RX Monitoring is actually passing the data along to the MAC.

Regards,

Alvaro

Hello Alvaro, Thank you for your quick response and glad to interest in to my problem. I realy appriciated. I am realy thanks to understand my situation.
This weekend i will execute hardware test abouth RX signals.
Best Regards
Volkan

Hi Volkan,

Always glad to help. Please probe any RX_Data pin, i.e. RX_D0 or RX_D1 vs the 50 MHz clock. This would be the most helpful scope plot.

Thanks for clarifying first, see you on Monday!

Regards,

Alvaro

Hello Alvaro, i have done some probe tests with RX lines;
RX Lines both Normal Mode and extender mode are OK;

Any comment i appriciate
Best Regards

Hi Volkan!

Apologies for the delay in response. Thank you for capturing these scope shots!

This to me confirms that the DP83849 RX_Monitoring feature is operating as expected, where the data is being sent to the MAC. The problem, as you suspected, may lie in the code. Unfortunately my ability to help you debug this is limited. When the PHY is in Extender mode and the data is being sent to the MAC, how is the MAC receiving this data?

Regards,

Alvaro

Hello Alvaro. Glad to hear from you again.
Yes i agree with you, hardware works well. I suspect programming code as well.
Best Regards
Volkan

Hi Volkan,

I am also unfamiliar with the functions you are referring to, but I would start by "Following the data". Try to find where the data is first being received and follow each function call from there. I apologize for not being able to assist further.

Regards,

Alvaro