• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 372 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS570LC4357: Ethernet bootloader

TMS570LC4357: When switching from bootloader to application, the application get stuck at etharp_gratuitous(netif)

Adrian Craciun
Prodigy 15 points
Part Number: TMS570LC4357

I use the Ethernet bootloder provided by TI () and a custom application.

Both bootloader and my application are using the lwip.

When switching from bootloader to application, the application get stuck in netif_set_up() function when it tries to execute etharp_gratuitous(netif)

After executing (in my application) the function etharp_gratuitous(netif), the bootloader "Interrupt Handler for Core 0 Transmit interrupt" function (EMACCore0TxIsr) is called continuously.

My problem seems to be similar with the one described in: e2e.ti.com/.../2365450 but in that ticket there is no solution provided.

Thank you,

Adrian

  • 0
    TI__Guru**** 197356 points

    Hi Adrian,

    Please disable the interrupt before switching to the application image. After switched to application, the VIM table should be re-initialized for your application. 

  • 0 in reply to QJ Wang
    Prodigy 15 points

    Hi QJ,

    First of all, thank you for your fast response.

    Going back to your recommendation, I already did that (disable the interrupt) before switching to the application image.

    The behavior that I've described is happen with the code that contain the disable statements.

    Please see below the main function of the bootloader:

    void main(void)
    {
     /* USER CODE BEGIN (3) */
        unsigned int ipAddr;
        g_pulUpdateSuccess[1]= APP_START_ADDRESS;
        g_pulUpdateSuccess[3] = 0x20002021;  /*version number, 02.00, in 2021*/
        esmREG->SR1[0] = 0xFFFFFFFF;
        esmREG->SR1[1] = 0xFFFFFFFF;
        esmREG->SR1[2] = 0xFFFFFFFF;
        esmREG->SR4[0] = 0xFFFFFFFF;
        esmREG->EKR = 0x0A;
        esmREG->EKR = 0x00;
        /* Copy the flash APIs to SRAM*/
        memcpy(&apiRunStart, &apiLoadStart, (uint32)&apiLoadSize);
        sciInit();
        gioInit();
        sciSetBaudrate(UART, UART_BAUDRATE);
        /* Enable the interrupt generation in CPSR register */
        _enable_IRQ();
        UARTprintf("    \n\r ");
        UARTprintf("Ethernet lwIP Bootloader \n\r");
        uint8 ip_addr[4] = { 169, 254, 9, 206 };
        uint8 netmask[4] = { 255, 255, 255, 0 };
        uint8 gateway[4] = { 169, 254, 9, 255 };
        ipAddr = 0;
        while(ipAddr == 0)
        {
            ipAddr = lwIPInit(0, emacAddress,
                                 *((uint32_t *)ip_addr),
                                 *((uint32_t *)netmask),
                                 *((uint32_t *)gateway),
                                 IPADDR_USE_STATIC);
        }

        UARTprintf("HDK IP Address: ");
        DisplayIPAddress (ipAddr);
        UARTprintf("    \n\r ");
        UARTprintf("    \n\r ");
        UARTprintf("Load Application using tftp \n\r");
        TFTPQSInit();
        UARTprintf("\n\rStart loaded application \n\r");
        _disable_IRQ();
        _disable_FIQ();
        g_ulTransferAddress = (uint32_t)APP_START_ADDRESS;
        ((void (*)(void))g_ulTransferAddress)();
        /* USER CODE END */
    }

    As it can be seen above, I disable the interrupts before switching to the loaded custom application.

    Is the above interrupt disable incomplete or do I miss something?

    The reported behavior can be seen in the bootloader+application traces presented below:

     Ethernet lwIP Bootloader
            DEBUG - Getting PHY ID....SUCCESS
            DEBUG - Getting PHY Alive Status...SUCCESS
            DEBUG - Getting PHY Link Status...SUCCESS
            DEBUG - Setting up Link...SUCCESS
    Bootloader countEMACCore0TxIsr=1
    HDK IP Address: 169.254.9.206
     Load Application using tftp
    Bootloader countEMACCore0RxIsr=1
    Erasing flash ......
    Erase Done!
    Bootloader countEMACCore0TxIsr=2
    Bootloader countEMACCore0RxIsr=2
    Bootloader countEMACCore0TxIsr=3
    Bootloader countEMACCore0RxIsr=3
     Block 1 has been programmed!
    Bootloader countEMACCore0TxIsr=4
    Bootloader countEMACCore0RxIsr=4
     Block 2 has been programmed!
    Bootloader countEMACCore0TxIsr=5
    Bootloader countEMACCore0RxIsr=5
     Block 3 has been programmed!
    Bootloader countEMACCore0TxIsr=6
    Bootloader countEMACCore0RxIsr=6
    ............................
     Block 355 has been programmed!
    Bootloader countEMACCore0TxIsr=358
    Bootloader countEMACCore0RxIsr=358
     Block 356 has been programmed!
    Bootloader countEMACCore0TxIsr=359
    Bootloader countEMACCore0RxIsr=359

    Fapi_setActiveFlashBank return =0
    Fapi_enableEepromBankSectors return =0
    Fapi_issueAsyncCommandWithAddress return =0
    Fapi_issueProgrammingCommand return =0
    Fapi_issueProgrammingCommand return =0
    Fapi_issueProgrammingCommand return =0
    Fapi_issueProgrammingCommand return =0

     Application was loaded successful! 
    Bootloader countEMACCore0TxIsr=360
    Start loaded application
     --- Custom application main function called ---
     --- Custom application before lwIPDeInit ---
    netif_set_up before etharp_gratuitous
    Bootloader countEMACCore0TxIsr=361
    Bootloader countEMACCore0TxIsr=362
    Bootloader countEMACCore0TxIsr=363
    Bootloader countEMACCore0TxIsr=364
    Bootloader countEMACCore0TxIsr=365
    ………………………………...

    In the above logs, you can see the switch between bootloader and application.

    In application, when lwIPDeInit is called, the bootloader "Interrupt Handler for Core 0 Transmit interrupt" function (EMACCore0TxIsr) is called continuously.

    Thank you,

    Adrian CRACIUN

  • 0 in reply to Adrian Craciun
    TI__Guru**** 197356 points

    The interrupt is not disabled. Please check CPSR register if the I and F bits are set.

    Before disable IRQ, would you please disable CTXPULSE interrupt generation (C0TXEN register) and disable emac TX interrupt (RXINTMASKCLEAR register)?

  • 0 in reply to QJ Wang
    Prodigy 15 points

    Hi QJ

    I've checked the CPSR register before and after _disable_IRQ() and the I saw that I and F bits are set correctly.

    Before _disable_IRQ(), I've also disabled CTXPULSE interrupt generation (C0TXEN register) and disabled emac TX interrupt (RXINTMASKCLEAR register) as you recommended but there is no improvement. We still encounter the reported issue.

    Than, Ive disable also the TXINTMASKCLEAR and C0RXEN but the issue was still present.

    1. Please see below two snapshots taken before _disable_IRQ() in which you can see the values of the I and F bits (CPSR register) and the value of C0TXEN, C0RXEN, RXINTMASKCLEAR  and TXINTMASKCLEAR

    2. Please see below two snapshots taken after _disable_IRQ() in which you can see the values of the I and F bits (CPSR register) and the value of C0TXEN, C0RXEN, RXINTMASKCLEAR  and TXINTMASKCLEAR

    Thank you,

    Adrian Craciun

  • +1 in reply to Adrian Craciun
    Prodigy 15 points

    Hi QJ,

    I've managed to identify and correct the problem.

    The problem was caused by the missing vimInit() function call when we switch from bootloader to application and from application to bootloader.

    Because of this, when we enter in the application, the pointer to the function EMACCore0RxIsr was the one set by bootloader.

    I've add in both application and bootloader HL_sys_startup.c file, a new case for NO_RESET which will force some reinitializations to take place (including the call to vimInit() ) when we switch from bootloader to application and from application to bootloader.

    Thank you,

    Adrian Craciun