[Ethernet] iLLD driver issue on TC29x

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hello everbody,

I am trying to run the Eth demo application from iLLD on a TC297. The uC is getting stuck in the busy wait for the Transmission Completed Flag
 while (IfxEth_isTxInterrupt(&g_Eth.drivers.eth) == FALSE) 
.

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.

Has anybody faced this problem or has a hint on how to solve or to explore it better?

Thank you!

Kind regards,
Vitor
0 Likes
9 Replies
Not applicable
Hi, are you trying to get this to work in loopback mode?

The demo code from Infineon works in loopback mode, but when you try to communicate with the PHY, nothing works.
There is an error on the pin config in the demo code, but even if you fix it, the PHY doesn't function.


Any updates?
0 Likes
Not applicable
audiolines wrote:
Hi, are you trying to get this to work in loopback mode?

The demo code from Infineon works in loopback mode, but when you try to communicate with the PHY, nothing works.
There is an error on the pin config in the demo code, but even if you fix it, the PHY doesn't function.


Any updates?


Yes, I haven't modified the application demo, that configures the GMAC in loopback mode and the issue I reported is happening anwway. Do you observe the same also in loopback?

Kind regards,
Vitor
0 Likes
Not applicable
I debugged the code once again with the help of my Master Thesis Mentor here in Toyota Motorsport.

The problem was that the DMA was receiving the local addresses of the Descriptor Lists (for Tx and Rx), addresses starting with 0xD......
However, these addresses are in the RAM of core0. Therefore we should pass the global addresses of the lists. I don't know how this demo was working for other people without the fix, maybe some specific setting on the compiler/linker to work with global addresses only, I am not sure.

Anyway, my fix was to change the functions which return the baseRxDescriptor and baseTxDescriptor to return the global address of the lists, instead of the local ones. In the case of the TC297, the local RAM addresses start with 0xD... and the global RAM addresses start with 0x7.... instead. However, there is a macro which already makes the conversion. If you observe, this macro was already being used to set the addresses of the buffers, but for some reason it was not being used to set the addresses of the descriptor lists.

For the buffer addresses, in the IfxEth.c the iLLD does:
#if !IFXETH_TX_BUFFER_BY_USER
IfxEth_TxDescr_setBuffer(descr, &(IfxEth_txBuffer[0]));
#endif


With:
IFX_INLINE void IfxEth_TxDescr_setBuffer(IfxEth_TxDescr *descr, void *buffer)
{
descr->TDES2.U = (uint32)IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), buffer);
}


Therefore, I modified the functions which return the addresses of the descriptors lists, as I mentioned:
IFX_INLINE IfxEth_RxDescr *IfxEth_getBaseRxDescriptor(IfxEth *eth)
{
return (IfxEth_RxDescr*) IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), eth->rxDescr->items);
//return eth->rxDescr->items;
}


IFX_INLINE IfxEth_TxDescr *IfxEth_getBaseTxDescriptor(IfxEth *eth)
{
return (IfxEth_TxDescr*) IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), eth->txDescr->items);
//return eth->txDescr->items;
}


I still haven't tested with loopbackmode disabled.

I hope it helps.

Kind regards,
Vitor Roriz
0 Likes
Not applicable
Hi vitorroriz,


Yes- I found the same issue regarding the addressing on the descriptor.
I came up with a similar solution as you, I ended up just hard-coding the address to be 100% sure the address was correct.

However,
if you then remove the loopback mode, you might see that you're unable to send data out the Ethernet port (through the PHY)

I'm still trying to find the solution.... *Using TC297 TFT appkit.
0 Likes
Not applicable
How are you testing the sent frames? I thought I was alsing having problems but Wireshark was filtering some packages. Can you obveserve some activity in the output pins with an osciloscope?
0 Likes
Not applicable
Have you found a solution? I applied the changes presented by vitorroriz and it works sometimes, but also randomly crashes and enters the debug state or does not send anything anymore. I can't find the reason for this behaviour. The frames sent are visible in Wireshark, even when LoopBack is enabled.
I'm working with a TriBoard V1.0 and TC297TF-128.
0 Likes
Not applicable
I've found other bug that may help you.

In my evaluation board, the pin defined for MDIO is not bidirectional. This has some implications in the iLLD PHY driver. For the non-bidirectional pin, the default config makes the MDIO pin to be just an output pin (let's call ut MDO then). When the driver tries to read the PHY registers with the MDO it will obviously not work properly. This cause the initialization function to not wait for the PHY to reset, since this busy-wait relies on the Read of a PHY register. I observed that this cause my PHY to not be configured correctly, by watching the clock pin with an oscilloscope and observing that the frequency was not the one configured. As a "temporary hack", until we migrate the microcontroller to our own board and change the pin mapping, I made dummy sleep function to wait the PHY to reset, by around 200ms. This fixed the issue for me.

P.S.: If you observe the clock pin with a oscilloscope, it is recommended to disattach the probe after your measurments, because I observed many ETH frames not arriving, due to, probably, too much current being drained by my probe.
0 Likes
User18140
Level 1
Level 1
Welcome! First reply posted
vitorroriz wrote:
I debugged the code once again with the help of my Master Thesis Mentor here in Toyota Motorsport.

The problem was that the DMA was receiving the local addresses of the Descriptor Lists (for Tx and Rx), addresses starting with 0xD......
However, these addresses are in the RAM of core0. Therefore we should pass the global addresses of the lists. I don't know how this demo was working for other people without the fix, maybe some specific setting on the compiler/linker to work with global addresses only, I am not sure.

Anyway, my fix was to change the functions which return the baseRxDescriptor and baseTxDescriptor to return the global address of the lists, instead of the local ones. In the case of the TC297, the local RAM addresses start with 0xD... and the global RAM addresses start with 0x7.... instead. However, there is a macro which already makes the conversion. If you observe, this macro was already being used to set the addresses of the buffers, but for some reason it was not being used to set the addresses of the descriptor lists.

For the buffer addresses, in the IfxEth.c the iLLD does:
#if !IFXETH_TX_BUFFER_BY_USER
IfxEth_TxDescr_setBuffer(descr, &(IfxEth_txBuffer[0]));
#endif


With:
IFX_INLINE void IfxEth_TxDescr_setBuffer(IfxEth_TxDescr *descr, void *buffer)
{
descr->TDES2.U = (uint32)IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), buffer);
}


Therefore, I modified the functions which return the addresses of the descriptors lists, as I mentioned:
IFX_INLINE IfxEth_RxDescr *IfxEth_getBaseRxDescriptor(IfxEth *eth)
{
return (IfxEth_RxDescr*) IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), eth->rxDescr->items);
//return eth->rxDescr->items;
}


IFX_INLINE IfxEth_TxDescr *IfxEth_getBaseTxDescriptor(IfxEth *eth)
{
return (IfxEth_TxDescr*) IFXCPU_GLB_ADDR_DSPR(IfxCpu_getCoreId(), eth->txDescr->items);
//return eth->txDescr->items;
}


I still haven't tested with loopbackmode disabled.

I hope it helps.

Kind regards,
Vitor Roriz



Thank you for posting this. I found the same problem and was able to move forward with this fix
0 Likes
User20321
Level 1
Level 1
5 replies posted First reply posted First question asked
Hi,
I have a similar issue: The uC is getting stuck in the busy wait for the Transmission Completed Flag but only when the debugger is disconnected.

When I use the debugger everything works fine, I can send and receive frames on the ethernet.

But when I reset the card, the receive buffer stays empty and the uC is getting stuck in the busy wait for the Transmission Completed Flag.

I use a tc299 1.1 triboard and aurix Developement Studio.

As anyone experienced similiar issues ?

Regards,
Octave
0 Likes