Hi,
I am trying to get a new design working: It is very close to the xCORE-200 MC AUDIO Reference Design, but the processor is replaced with XUF232-1024-FB374 and there is a switch instead of the PHY.
Sending Ethernet-Frames with Gigabit-Speed works fine. So I assume that the switch is configured properly. The RX-clock is running with 125MHz as well. And it is in RGMII mode after reset.
The problem is that I do not receive any Ethernet-Frames. (Setting break points in rgmii_ethernet_rx_server(...))
get_current_rgmii_mode(...) always returns INBAND_STATUS_OFF.
Is the inband status commonly used on all PHYs and switches? In the datasheet I can not find anything regarding something like an "inband status".
I tried to set the status permanently to INBAND_STATUS_1G_FULLDUPLEX_UP, because the link to the switch is always active. But with no success.
Any ideas how to debug?
Using TSN-/Ethernet-Lib with other PHYs/Switches Topic is solved
-
- Member
- Posts: 15
- Joined: Tue Sep 24, 2013 1:07 pm
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Hi fabib,
I am not sure whether in-band status is a mandatory part of the RGMII specification, but it does seem to be quite common:
http://ww1.microchip.com/downloads/en/D ... 031RNX.pdf - page 27
http://www.mouser.com/ds/2/268/ksz9021r ... 778083.pdf - page 32
If your PHY is not signalling its speed using the in-band status notification then you could at least set the speed as a fixed speed of 1G by changing the INITIAL_MODE define in rgmii_consts.h to to be INBAND_STATUS_1G_FULLDUPLEX and then commenting out the following code in rgmii_buffering.xc and the target will stay at a fixed 1G.
Regards,
Peter
I am not sure whether in-band status is a mandatory part of the RGMII specification, but it does seem to be quite common:
http://ww1.microchip.com/downloads/en/D ... 031RNX.pdf - page 27
http://www.mouser.com/ds/2/268/ksz9021r ... 778083.pdf - page 32
If your PHY is not signalling its speed using the in-band status notification then you could at least set the speed as a fixed speed of 1G by changing the INITIAL_MODE define in rgmii_consts.h to to be INBAND_STATUS_1G_FULLDUPLEX and then commenting out the following code in rgmii_buffering.xc and the target will stay at a fixed 1G.
Code: Select all
case tmr when timerafter(t) :> t:
rgmii_inband_status_t new_mode = get_current_rgmii_mode(p_rxd_interframe, current_mode, speed_change_ids);
if (new_mode != current_mode) {
current_mode = new_mode;
done = 1;
}
t += rgmii_mode_poll_period_ms * XS1_TIMER_KHZ;
break;
Peter
-
- Member
- Posts: 15
- Joined: Tue Sep 24, 2013 1:07 pm
Hi Peter,
good idea. It shouldn't be a problem to configure it staticly on my target, because I have always a Gigabit link.
using #define INITIAL_MODE INBAND_STATUS_1G_FULLDUPLEX gives the following error:
Description Resource Path Location Type
use of undeclared identifer `INBAND_STATUS_1G_FULLDUPLEX' rgmii_ethernet_mac.xc /lib_ethernet/src line 134 C/C++ Problem
INBAND_STATUS_1G_FULLDUPLEX is not defined.
So I use INBAND_STATUS_1G_FULLDUPLEX_UP instead.
Now I can build without errors, but
#if INITIAL_MODE == INBAND_STATUS_1G_FULLDUPLEX
is still in the code. Strange behaviour that this doesn't result in an error.
I replaced this with INBAND_STATUS_1G_FULLDUPLEX_UP as well.
The reference design is still running with this code.
I will check it on my target next week.
---
Update:
I have checked these modifications on my board, but it is not receiving any data. I have tested both: 100Mbit and 1GBit. The RX and TX Clocks are working at 25 / 125 MHz depending on the configured RGMII speed. So I assume that my PHY is configured correctly.
---
Thanks,
Fabian
good idea. It shouldn't be a problem to configure it staticly on my target, because I have always a Gigabit link.
using #define INITIAL_MODE INBAND_STATUS_1G_FULLDUPLEX gives the following error:
Description Resource Path Location Type
use of undeclared identifer `INBAND_STATUS_1G_FULLDUPLEX' rgmii_ethernet_mac.xc /lib_ethernet/src line 134 C/C++ Problem
INBAND_STATUS_1G_FULLDUPLEX is not defined.
So I use INBAND_STATUS_1G_FULLDUPLEX_UP instead.
Now I can build without errors, but
#if INITIAL_MODE == INBAND_STATUS_1G_FULLDUPLEX
is still in the code. Strange behaviour that this doesn't result in an error.
I replaced this with INBAND_STATUS_1G_FULLDUPLEX_UP as well.
The reference design is still running with this code.
I will check it on my target next week.
---
Update:
I have checked these modifications on my board, but it is not receiving any data. I have tested both: 100Mbit and 1GBit. The RX and TX Clocks are working at 25 / 125 MHz depending on the configured RGMII speed. So I assume that my PHY is configured correctly.
---
Thanks,
Fabian
-
- Member
- Posts: 15
- Joined: Tue Sep 24, 2013 1:07 pm
An error interrupt is raised all the time... (mii_error_interrupt_handler).
Is there a way to get some information about the causation for that?
Is there a way to get some information about the causation for that?
-
- Member
- Posts: 15
- Joined: Tue Sep 24, 2013 1:07 pm
Constraints check gives the following warning:
xmap: Warning: port "XS1_PORT_1B" on tile[1] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_1A" on tile[1] is not connected to any pins in this package.
The XEF232-1024-FB374 Datasheet - p. 23 says that this pins are connected.
This is the RGMII_PORTS_INITIALIZER from the reference design:
#define RGMII_PORTS_INITIALIZER { \
XS1_PORT_1O, \
XS1_PORT_1A, \
XS1_PORT_8A, \
XS1_PORT_4E, \
XS1_PORT_4F, \
XS1_PORT_1B, \
XS1_PORT_1K, \
XS1_PORT_1P, \
XS1_PORT_1G, \
XS1_PORT_1E, \
XS1_PORT_1F, \
XS1_PORT_8B, \
XS1_CLKBLK_1, \
XS1_CLKBLK_2, \
XS1_CLKBLK_3, \
XS1_CLKBLK_4 \
}
---
moved to a new topic since this seems to be a compiler issue: http://www.xcore.com/forum/viewtopic.php?f=37&t=5005
xmap: Warning: port "XS1_PORT_1B" on tile[1] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_1A" on tile[1] is not connected to any pins in this package.
The XEF232-1024-FB374 Datasheet - p. 23 says that this pins are connected.
This is the RGMII_PORTS_INITIALIZER from the reference design:
#define RGMII_PORTS_INITIALIZER { \
XS1_PORT_1O, \
XS1_PORT_1A, \
XS1_PORT_8A, \
XS1_PORT_4E, \
XS1_PORT_4F, \
XS1_PORT_1B, \
XS1_PORT_1K, \
XS1_PORT_1P, \
XS1_PORT_1G, \
XS1_PORT_1E, \
XS1_PORT_1F, \
XS1_PORT_8B, \
XS1_CLKBLK_1, \
XS1_CLKBLK_2, \
XS1_CLKBLK_3, \
XS1_CLKBLK_4 \
}
---
moved to a new topic since this seems to be a compiler issue: http://www.xcore.com/forum/viewtopic.php?f=37&t=5005
-
- Member
- Posts: 15
- Joined: Tue Sep 24, 2013 1:07 pm
It was the "RGMII Tx Timing"-Bit that had to be configured properly. Confusing datasheet...
-
- Junior Member
- Posts: 5
- Joined: Fri Apr 13, 2018 6:32 am
Hi Fabib,
Sorry for my question, but i have the same error with KSZ9031, and i don't understand the fix problems with "RGMII Tx Timing" ?
Thank you ,
Sorry for my question, but i have the same error with KSZ9031, and i don't understand the fix problems with "RGMII Tx Timing" ?
Thank you ,
-
- Member++
- Posts: 22
- Joined: Mon Sep 26, 2016 6:08 pm
I am also having this same issue. We have an 88E6320 switch instead of a PHY, and while I can transmit, I do not receive any Ethernet frames. I see that enable_rgmii() takes a delay and divider, but I have not found any documentation or examples on how to adjust these. The switch also has a timing delay which may be enabled on for RX and TX modes. Can anyone clarify what might need to be changed here?
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Out of interest, is there any special software that would need to be written for the XMOS part to use a switch instead of a PHY in the TSN operation? What I want to do is to make an GbE AVB/TSN daisy chain. The designs I am aware of need a processor in addition to the switch (e.g. MOTU AVB switch) and to be honest I don't know if those processors are doing packet processing or just configuring the switch or doing something else for the AVB/TSN function. Maybe I should raise this as a different topic but all the posters seem to be doing something along these lines.
-
- Member++
- Posts: 22
- Joined: Mon Sep 26, 2016 6:08 pm
I have this working. The mysterious "RGMII Tx Timing"-Bit mentioned by the OP was actually a setting in the switch, which has a delay that can be enabled for receive and transmit sides of the RGMII interface. I needed to enable it on the switch port's transmit side (the XMOS's receive side), as well as address some issues with the clock signal at XMOS startup.cjameshuff wrote:I am also having this same issue. We have an 88E6320 switch instead of a PHY, and while I can transmit, I do not receive any Ethernet frames. I see that enable_rgmii() takes a delay and divider, but I have not found any documentation or examples on how to adjust these. The switch also has a timing delay which may be enabled on for RX and TX modes. Can anyone clarify what might need to be changed here?