Not applicable
May 07, 2018
04:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 07, 2018
04:53 AM
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
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
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
9 Replies
Not applicable
May 07, 2018
07:11 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 07, 2018
07:11 PM
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?
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?
Not applicable
May 08, 2018
12:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 08, 2018
12:07 AM
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
Not applicable
May 10, 2018
11:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 10, 2018
11:37 PM
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:
With:
Therefore, I modified the functions which return the addresses of the descriptors lists, as I mentioned:
I still haven't tested with loopbackmode disabled.
I hope it helps.
Kind regards,
Vitor Roriz
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
Not applicable
May 24, 2018
05:56 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 24, 2018
05:56 PM
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.
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.
Not applicable
Jun 01, 2018
12:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 01, 2018
12:21 AM
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?
Not applicable
Jul 18, 2018
03:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 18, 2018
03:34 AM
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.
I'm working with a TriBoard V1.0 and TC297TF-128.
Not applicable
Jul 18, 2018
04:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 18, 2018
04:08 AM
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.
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.
Oct 31, 2019
01:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 31, 2019
01:44 PM
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
Oct 16, 2020
04:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 16, 2020
04:44 AM
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
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