• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 29 subscribers
  • Views 218 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.

TM4C129ENCPDT: Ethernet Failing to Re-start

Hairy Lee
Prodigy 200 points
Part Number: TM4C129ENCPDT

Hello,

From a hard reset the ethernet starts up fine in the bootloader, which then shuts it down. The application then re-enables and resets the ethernet using the same code as used in the bootloader; at this point startup is unreliable. 

Other than:

EMACTxDisable(EMAC0_BASE);
EMACRxDisable(EMAC0_BASE);
SysCtlPeripheralDisable(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralDisable(SYSCTL_PERIPH_EPHY0);

is there anything else that needs to be called to shut it down?

Thanks,

HL

  • 0
    TI__Guru**** 159385 points

    Hi Hairy,

      is it the shutdown that is causing an issue or is it the re-enabling of the Ethernet after it has been shut down?

    I'm not sure if the below errata is affecting what you are doing. 

    When you re-enable the Ethernet again can you do:

    1. Write 1 to the FPFOFF bit to disable the prefetch buffers
    2. Initialize EMAC and PHY
    3. Write 1 to the FPFON bit to enable the prefetch buffers

      

  • 0 in reply to Charles Tsai
    Prodigy 200 points

    Hi Charles,

    The reason why I suspcted the shutdown process is because the bootloader is running in flash, but the application is running from RAM. Sorry, I should have mentioned this, but for some reason when I first came to post the question I was experiencing issues accessing the forum. When I came back to it, it was late and had been a long day.

    A proposed fix was to not initialise the Ethernet in the bootloader. This has been implemented but made things worse. It seems to be execution speed that causes the issue as having added delays into the tivaware init routine seems to fix the issue. Can you provide any insight as to why this might be?

  • 0 in reply to Hairy Lee
    TI__Guru**** 159385 points

    Hi Hairy,

    Hairy Lee said:
    It seems to be execution speed that causes the issue as having added delays into the tivaware init routine seems to fix the issue.

    Can you please elaborate what and where the delay did you add to fix the issue. I'd like to share with the community incase the same issue (I have not heard so far other than you) is faced by other people in the future. I'm also not clear as to why execution speed plays a role leading to the issue unless it is related to the errata I mentioned in my last reply for which a workaround was suggested. 

  • 0 in reply to Charles Tsai
    Prodigy 200 points

    Hi Charles,

    Search for DelayMs(). It is by no means correct, but it seems to have resolved our issue (for the time being?). Might the fact that it is running from RAM and the additional speed that provides be causing the problem and thus the need for the delays?  

    emac.c

  • 0 in reply to Hairy Lee
    TI__Guru**** 159385 points

    Hi Hairy,

      I really don't understand why you would need the delayMs() after many of the writes to the MAC registers. Perhaps I just don't understand the problem you facing. Can you please elaborate the below statement again. 

    Hairy Lee said:
    The application then re-enables and resets the ethernet using the same code as used in the bootloader; at this point startup is unreliable. 

    When you use the TivaWare boot_emac_flash (the bootloader) and the boot_demo_emac_flash (the application) did you experience the same problem as you are facing now?

    If you look at the boot_emac_flash bootloader, I don't think it shuts down the Ethernet. The bootloader will configure the EMAC and determines if it will just jump to the application or start bootloading if there is no application image. Please look at the bl_startup_css.s file. Whether or not the application is already present, the EMAC is configured and as far as I can tell, there is no shutting down of the EMAC. Suppose the application is already present, the bootloader just jumps to the application to start. Once in the application (using boot_demo_emac_flash as the example), it simply calls the LwIPInit() to initiate EMAC configuration and start the stack. What I want to say is that there is no shutting down of the EMAC. Is there any reason why you want to shut down the EMAC in the bootloader? What if you don't shut down the EMAC in bootloader, do you see any difference?

  • 0 in reply to Charles Tsai
    Prodigy 200 points

    Hello Charles,

    No we didn't use the TivaWare bootloader example as we already have an implementation (albeit for a different platform that has been ported to the TM4C129). Its not unusual to want to shut the ethernet down during normal operation nor is it when swtiching from a bootloader to an application. The application is then in full control of the peripherals that are enabled as it is responsible for bringing them up in a known state.

    With regards to the aforementioned errata is the work around provided to over come execution speed or a side effect as it is not clear?

    Thanks 

    HL

  • +1 in reply to Hairy Lee
    TI__Guru**** 159385 points

    Hi Hairy,

      If it is your own bootloader then we can't really support it as we have no knowledge about it. But if you have proven the delayMS() you added would solve the unstable issue then I will suggest you stay with the solution. 

     As far as the errata, I feel it is somehow similar to your problem description. Would you give it a try in your bootloader where you would first turn off the flash prefetch buffer before initializing the Ethernet. Will it make any difference?

      Also wanted to give a heads-up. I will be out of office for the rest of the week and will not be able to respond to forum. 

  • 0 in reply to Charles Tsai
    Prodigy 200 points

    Hello Charles,

    Yes of course I appreciate you cant help with our bootloader. We have tried using the work around in the errata and it made no difference.

    Thanks,

    HL