Not applicable
Apr 13, 2018
05:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 13, 2018
05:26 AM
Hello,
I’m using a 2nd generation AURIX TC3xx starter kit (TriBoard) and tried to run the Ethernet Demo supplied with the iLLD 1.0.1.3.0 TC39A without success.
The Demo can be compiled and programmed, but the communication with the PHY PEF7071 mounted on the board seems to be unsuccessful as they program will wait for the Transmission-Complete-Interrupt to be set which never happens.
The functions provided by the IfxEth library seem to have no effect, reading out the registers of the PHY using the IfxEth_Phy_Pef7071 library shows that there are no changes done.
The mdio read and write functions provided by IfxEth_Phy_Pef7071 work as they should.
I’m using a 2nd generation AURIX TC3xx starter kit (TriBoard) and tried to run the Ethernet Demo supplied with the iLLD 1.0.1.3.0 TC39A without success.
The Demo can be compiled and programmed, but the communication with the PHY PEF7071 mounted on the board seems to be unsuccessful as they program will wait for the Transmission-Complete-Interrupt to be set which never happens.
The functions provided by the IfxEth library seem to have no effect, reading out the registers of the PHY using the IfxEth_Phy_Pef7071 library shows that there are no changes done.
The mdio read and write functions provided by IfxEth_Phy_Pef7071 work as they should.
8 Replies
Not applicable
May 07, 2018
06:17 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 07, 2018
06:17 AM
I am facing the same issue using the TC297.
As I mentioned in my thread:
By debugging I realized that the DMA never gets the chance to access the Tx Buffer, as it is always setting TU = 1 (TU stands for Transmit Buffer Unavailable) on the DMA Reg5 (Status Reg). This happens when the DMA accesses the Tx Descriptor and reads Own bit = 0, what means that the Host owns the Descriptor (and therefore the DMA does not own it).
I have already checked the Register TDESLA_32BIT that holds the Addr of the Descriptor list and it is holding the correct addr. I have also already verified that the Own bit is being correctly set to Own = 1 before the poll demand on the DMA, delivering the ownership of the descriptor to the DMA.
As I mentioned in my thread:
By debugging I realized that the DMA never gets the chance to access the Tx Buffer, as it is always setting TU = 1 (TU stands for Transmit Buffer Unavailable) on the DMA Reg5 (Status Reg). This happens when the DMA accesses the Tx Descriptor and reads Own bit = 0, what means that the Host owns the Descriptor (and therefore the DMA does not own it).
I have already checked the Register TDESLA_32BIT that holds the Addr of the Descriptor list and it is holding the correct addr. I have also already verified that the Own bit is being correctly set to Own = 1 before the poll demand on the DMA, delivering the ownership of the descriptor to the DMA.
Not applicable
May 07, 2018
07:08 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 07, 2018
07:08 PM
I was still unable to communicate over Ethernet on TC297 or TC3xx Starter kit.
I also read the user manual and cross checked the Register Values.
Still, there is nothing from the PHY.. I also noticed the issue vitorrriz is talking about and tried to even code my own descriptors just for a sanity check.
Still, nothing.
Any ideas on how to solve this? Is it working for you?
I also read the user manual and cross checked the Register Values.
Still, there is nothing from the PHY.. I also noticed the issue vitorrriz is talking about and tried to even code my own descriptors just for a sanity check.
Still, nothing.
Any ideas on how to solve this? Is it working for you?
Mar 22, 2019
12:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 22, 2019
12:35 AM
audiolines wrote:
I was still unable to communicate over Ethernet on TC297 or TC3xx Starter kit.
I also read the user manual and cross checked the Register Values.
Still, there is nothing from the PHY.. I also noticed the issue vitorrriz is talking about and tried to even code my own descriptors just for a sanity check.
Still, nothing.
Any ideas on how to solve this? Is it working for you?
I managed to run the Ethernet with PHY' s loopback mode with RGMII configuration.
The PHY does work in loopback mode but doesn't work without loopback mode.
If someone was successful in running the ethernet, can you please help?
Jan 21, 2020
03:07 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 21, 2020
03:07 PM
Hi All in this thread,
I got the issue and can't use this demo to Tx anything to my PC that connect with Aurix ethernet. I changed MAC Dest address and no loopback and not check AutoNegotiation. But nothing can't be received in my connected PC side and the results as if it still as Loopback bit.
(
IFXETH_EPHY_RTL8211FG_init(…) function
bmcrData = 0x4340;
// from 0x5340 to 0x4340 --- loopback bit-12 to change from 1 to 0 and this supposed not loopback and msg should be Tx out to my PC. But the actual result is the Tx/Rx still loopack in Aurix and other Rx in PC by Wireshark monitor
)
If anyone has got GETH can communicate with a connected PC, please help. Thank you.
I got the issue and can't use this demo to Tx anything to my PC that connect with Aurix ethernet. I changed MAC Dest address and no loopback and not check AutoNegotiation. But nothing can't be received in my connected PC side and the results as if it still as Loopback bit.
(
IFXETH_EPHY_RTL8211FG_init(…) function
bmcrData = 0x4340;
// from 0x5340 to 0x4340 --- loopback bit-12 to change from 1 to 0 and this supposed not loopback and msg should be Tx out to my PC. But the actual result is the Tx/Rx still loopack in Aurix and other Rx in PC by Wireshark monitor
)
If anyone has got GETH can communicate with a connected PC, please help. Thank you.
Jan 22, 2020
01:04 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 22, 2020
01:04 PM
I've gotten Ethernet working on the TC234 ADAS.
If the TC3XX use the same Ethernet IP, then you will probably have to fix the same bugs.
This list of iLLD Ethernet bugs I found may help you.
https://www.infineonforums.com/threads/10716-iLLD-Ethernet-driver-bug-list
Toshi
If the TC3XX use the same Ethernet IP, then you will probably have to fix the same bugs.
This list of iLLD Ethernet bugs I found may help you.
https://www.infineonforums.com/threads/10716-iLLD-Ethernet-driver-bug-list
Toshi
Jan 23, 2020
11:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 23, 2020
11:08 AM
TMorita wrote:
If the TC3XX use the same Ethernet IP, then you will probably have to fix the same bugs.
TC2xx 100 Mbps Ethernet is different IP from TC3xx Gigabit Ethernet.
Jan 23, 2020
01:15 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 23, 2020
01:15 PM
UC_wrangler wrote:
TC2xx 100 Mbps Ethernet is different IP from TC3xx Gigabit Ethernet.
The TC2xx Ethernet is actually 10/100/1000 Mbps Ethernet.
Here's a quote from the TC21x/TC22x/TC23x Family Reference Manual:
"30.1.1 General Module Description
The DWC Ether MAC 10/100/1000 Universal, V3.7a, commonly referred to as GMACUNIV in this document, enables a host to transmit and receive data over Ethernet in
compliance with the IEEE 802.3-2002 standard. In TC21x/TC22x/TC23x it is configured to support 10 and 100 Mbit modes. Note that Gigabit mode is not configured,
nevertheless the core is referred to as GMAC to avoid confusion with other cores."
So it could be possible the TC2xx and TC3xx Ethernet are the same.
I don't have the TC3xx docs to check so I cannot prove or disprove it is the same.
According to the manual, the TC2xx series uses an internal APB bus, and not AXI.
My guess is gigE is disabled on the TC2xx series because APB doesn't have enough bandwidth to support gigabit Ethernet because APB is a synchronous bus.
Most SoCs that have gigE have AXI buses, which is an asynchronous split-transaction bus.
Toshi
Jan 24, 2020
03:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 24, 2020
03:50 AM
It's quite clear from the TC3xx docs that the IP is not the same.