• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 402 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: EMAC polling using LWIP

Adam Toews1
Prodigy 50 points
Part Number: TMS570LC4357

I am having issues with polling using the LWIP example program.

If I directly use the sample program, polling by calling the RX / TX ISR function as is works correctly.

When I attempt to integrate this exact code into my program I get stuck in the RX ISR in the while loop

while(hdkif_swizzle_data(curr_bd->flags_pktlen) & EMAC_BUF_DESC_SOP)

It is entering the RX handler immediately because rxintstatraw is set to 1, but stuck in the loop because

if((hdkif_swizzle_data(curr_bd->flags_pktlen) & EMAC_BUF_DESC_OWNER)
       != EMAC_BUF_DESC_OWNER)

This if statement is not satisfied. Therefore it skips all the code in the RX ISR handler and updates curr_bd with the following:

curr_bd = rxch->active_head;

but curr_bd has not updated and is still set to the same value. Even if I attempt to send an ethernet request to the device, it is still stuck in this loop and does not enter the if statement, nor exit the while loop.

I thought there might be an issue with the rxintstatraw register so I used this tickets enable of the MACINVECTOR register. But this register also gets set and I'm still stuck.

Is there any advice for where I might have gone wrong? I am currently using a static IP setup which reports on the SCI port a success

uint8 ip_addr[4] = { 172, 16, 0, 246 };
    uint8 netmask[4] = { 255, 255, 0, 0 };
    uint8 gateway[4] = { 172, 16, 0, 1 };
    ipAddr = lwIPInit(0, emacAddress,
        *((uint32_t *)ip_addr),
        *((uint32_t *)netmask),
        *((uint32_t *)gateway),
        IPADDR_USE_STATIC);

I have the same lwipopts and opts.h settings as the example program

  • 0
    TI__Guru 54870 points

    Hi Adam,

    Apologies for the delay, just now i started to look into your thread and will provide an update soon.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 50 points

    I actually solved the issue of getting stuck in the RX ISR last night. Turns out I had selected the MII when the example program had selected the RMII. When I swapped my program to select RMII it fixed my ISR getting stuck.

    PINMUX_ETHERNET_SELECT(RMII);

    When I attempt to go to the IP to view the website I get no response still though. So that would be my new problem.

  • 0 in reply to Adam Toews1
    Prodigy 50 points

    Actually this wasn't correct. switching from MII to RMII causes me to not receive packets at all. Which is odd because the example program works with selecting RMII on the same hardware. The pinmux is the same regarding EMAC / MDIO pins. SPI / GPIO / SCI pins are different for obvious reasons. The only other major difference is my VCLK4 / VCLK3 is 100Mhz vs the example programs 75Mhz. But I updated the CLKDIV for the MDIO to 99 from 74 to keep the MDIO clock at 1Mhz.

  • 0 in reply to Adam Toews1
    Prodigy 50 points

    I checked and the example program has 75Mhz VCLK3 and a 37.5 VCLKA4_DIV, 75Mhz VCLKA4_S. I think, if I recall correctly, in the TMS570 document it states that the EMAC logic is synched to the VCLKA4_DIV source. Which should be 37.5 in the example program?

    The only major issue I am seeing right now is that the EMAC fails to unset the ownership bit. Causing my RX int handler to get stuck. If I remove the if statement looking for the ownership bit I can correctly process Ethernet packets.

    It seems to be the reverse type issue that i see in this ticket where the user is getting stuck in the TX handler because the ownership bit is not being unset by the EMAC controller.

    I have tried with VCLKA4_DIV at 33Mhz and 50Mhz, but this hasn't solved the issue either. I'm a bit concerned about ignoring the EMAC_BUF_DESC_OWNER bit in the RX handler of my program.

  • 0 in reply to Adam Toews1
    TI__Guru 54870 points

    Hi Adam,

    Apologies for the delay, i stuck with other issue and i will try provide an update by Monday on this issue.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 50 points

    Hi Jagadish,

    Both of these links are related to the TX ISR function calling the incorrect one because of the VIM setup. Our program is using polling. Perhaps I confused you in my original post because I mentioned that I was stuck in the RX ISR handler. I did remove the VIM setup from the example program and modify it to use the polling method by checking the same flag register I am doing now.

    What I meant was I was stuck in the RX ISR handler function (that the example program uses as an ISR). I call this function after checking the flag register to see if we have had a new RX message.

    Once I have a new RX message, the program goes into the RX Handler function, but gets stuck when testing that the ownership bit has been unset by the EMAC indicating that it has finished receiving the entire message. (if the message was split into multiples, or it still needs to do some processing, the ownership bit would still be set by the EMAC).

    I have no issue with my pointers. They are correctly pointing to the peripheral RAM. the address is 0xFC521004.

    curr_bd->flags_pktlen = 0x3C0000E0, which after swizzle, has the EMAC_BUF_DESC_OWNER bit still set. I did check the initialization of the buffers and all we do is set the EMAC_BUF_DESC_OWNER bit for the various packets allocated to the EMAC RX handler which is also done in the example program.

  • 0 in reply to jagadish gundavarapu
    Prodigy 50 points

    I did change the example program from the default VCLK / HCLK of 75Mhz and 150Mhz, respectively, to the VCLK / HCLK that my program uses which is 100Mhz and 100Mhz, but the example program still unset the EMAC_BUF_DESC_OWNER bit properly.

    If I ignore this bit in the RX handler function, the EMAC / ethernet appears to work fine, but I don't really want to depend on some sort of behaviour that would be undefined like this and would like to find the reason why it's not working.

  • 0 in reply to Adam Toews1
    TI__Guru 54870 points

    Hi Adam,

    I need your complete project for debugging issue at my end. You can share as private message to me.

    Is that possible?

    --

    Thanks & regards,
    Jagadish.