infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 8 of 8

Thread: [Ethernet] iLLD driver issue on TC29x

  1. #1
    Beginner Beginner vitorroriz is on a distinguished road
    Join Date
    Apr 2018
    Posts
    6
    Points
    75

    [Ethernet] iLLD driver issue on TC29x

    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
    Code:
     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
    Last edited by vitorroriz; May 7th, 2018 at 07:18 AM. Reason: English misspelling

  2. #2
    Beginner Beginner audiolines is on a distinguished road
    Join Date
    May 2018
    Posts
    7
    Points
    100
    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?

  3. #3
    Beginner Beginner vitorroriz is on a distinguished road
    Join Date
    Apr 2018
    Posts
    6
    Points
    75
    Quote Originally Posted by audiolines View Post
    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

  4. #4
    Beginner Beginner vitorroriz is on a distinguished road
    Join Date
    Apr 2018
    Posts
    6
    Points
    75
    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:
    Code:
    #if !IFXETH_TX_BUFFER_BY_USER
            IfxEth_TxDescr_setBuffer(descr, &(IfxEth_txBuffer[i][0]));
    #endif
    With:
    Code:
    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:
    Code:
    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

  5. #5
    Beginner Beginner audiolines is on a distinguished road
    Join Date
    May 2018
    Posts
    7
    Points
    100
    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.

  6. #6
    Beginner Beginner vitorroriz is on a distinguished road
    Join Date
    Apr 2018
    Posts
    6
    Points
    75
    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?

  7. #7
    Beginner Beginner Sabulanis is on a distinguished road
    Join Date
    Apr 2018
    Posts
    3
    Points
    52.5
    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.
    Last edited by Sabulanis; Jul 18th, 2018 at 04:46 AM.

  8. #8
    Beginner Beginner vitorroriz is on a distinguished road
    Join Date
    Apr 2018
    Posts
    6
    Points
    75
    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.

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.