ethernet does NOT come up after ROM_UpdateEMAC

Please consider this a "hail mary" after waiting a long time and no better idea was posted.

I would try to determine how the processor's and mac's state differ from reset, after the bootloader has run. For example you may be able to halt the processor using jtag and examine its state. You may also be able to use jtag to dump the mac registers.

The fix in this case might be to load the mac registers with their default values on startup, or trigger a mac reset on startup, or it may be possible to trigger a full-chip reset. (Only triggered after a bootloader update)

Thanks David. 

    For now this idea is shelved, I couldn't get much traction on how to move forward.  I am trying a different approach now but will eventually come back to this to see if I can get it working.  I will definitely use your suggestions, thank you!

I think we're having the same problem with the EK-TM4C1294XL development board. We are following the same steps and running into the same issue, however I don't think it's an Ethernet issue. I don't think the board is being reset at all.

When we connect serially to the board we cannot connect to the updated application, until we do a reset using the reset button on the board. Our application blinks an LED when running, but just as posted above after flashing the updated application the LED remains on.

Hello Philip

If you connect the debugger w/o downloading any code, what does the TM4C Program Counter shows the execution location as?

Regards
Amit

I tried two of our other projects that both were able to update over Ethernet. One is a simple base project and the other is a slightly more complex project that uses the TM4C129NCPT processor on a custom board.

The project that is failing is now consistently landing at the following:

ti_sysbios_knl_Swi_runLoop__I() at Swi.c:184 0x0001D4DE

To get there I flash the board from CCS, disconnect CCS from the board, run the boot loader Ethernet update, and reconnect to the board from CCS.

Hello Philip

So 2 other projects which use Update over ethernet with TM4C129x work but not a 3rd project.

Can you check what Swi.c at line 184 is? Is it an Idle Process.

Regards
Amit

Line 184 attempts to refresh maxQ within the do/while block below.

/*
 *  ======== Swi_runLoop ========
 */
Void Swi_runLoop()
{
    Queue_Handle curQ, maxQ;
    Swi_Object *swi;

    /* Remember current Swi priority */
    curQ = Swi_module->curQ;

    /* refresh maxQ */
    maxQ = (Queue_Handle)((UInt8 *)(Swi_module->readyQ) +
           (UInt)(Intrinsics_maxbit(Swi_module->curSet)*(2*sizeof(Ptr))));

    /*
     * Run all Swis of higher priority than
     * the current Swi priority.
     * Will pre-empt any currently running swi.
     */
    do {
        swi = (Swi_Object *)Queue_dequeue(maxQ);

        /* remove from curSet if last one in this ready list */
        if (Queue_empty(maxQ)) {
            Swi_module->curSet &= ~swi->mask;
        }

        Swi_run(swi);

        if (Swi_module->curSet == 0) {
            break;
        }

        maxQ = (Queue_Handle)((UInt8 *)(Swi_module->readyQ) +
               (UInt)(Intrinsics_maxbit(Swi_module->curSet)*(2*sizeof(Ptr))));
    }
    while (maxQ > curQ);
}

Hello Philip

I would suggest checking with TI RTOS Forum/Team.

Regards
Amit

Sounds good. Thanks for the help anyway!

Did anyone find a solution to this? I have a TIVA TM4C1294NCPDT running CCS 6.1.2, TI-RTOS 1.16.0.08 and I have the same problem where after the update the Ethernet/ping no longer work.

The code I run before I do the update is:
HWREG(NVIC_DIS0) = 0xffffffff;
HWREG(NVIC_DIS1) = 0xffffffff;
HWREG(NVIC_DIS2) = 0xffffffff;
HWREG(NVIC_DIS3) = 0xffffffff;
HWREG(NVIC_DIS4) = 0xffffffff;
SysTickIntDisable(); // disable the systick interrupt
SysTickDisable(); // stop the systick counter
ROM_UpdateEMAC(g_ui32SysClock);

I can confirm that after I do the software update that the CPU is running the new code just downloaded from the update. After the software update, the new code is running as expected with the exception that the ping no longer works. If I then press the reset button to reset the board, then the ping and Ethernet start working again.

I found a workaround but I’m not sure why the work around works. My application uses the NDK stack for two TCP/IP sockets and it also uses USB. The USB is based on the sample application USB Bulk so it basically works the same way as the USB Bulk example. I found that after I do the software update using LM Flash with the Ethernet interface, I could talk to the CPU over USB using USB Bulk even though the Ethernet was not working (no ping). Since the USB bulk interface worked, I could change the version in the code, recompile the code, download the code and using the USB interface I could read the new version to confirm I was running the new code. When I did this “testing”, the board would not reply to the ping after the software update. If I reset the board, the board would answer the ping and talk via the sockets as expected and the USB interface also worked. For a quick test, I commented out in the code where I initialize the USB in the startup and after a firmware update, the board would ping as expected following a firmware update. I took a closer look at what I do to the processor before I call ROM_UpdateEMAC() and added one more step to disable the USB device before calling the function ROM_UpdateEMAC() . I also put the call back in to initialize the USB.

As you can see, I added the line USBDevDisconnect(USB0_BASE); to disable the USB device before I call ROM_UpdateEMAC(). Testing has shown that the call USBDevDisconnect(USB0_BASE); fixes something so after a firmware update both USB and the network stack work as expected.

// Disable all processor interrupts.

HWREG(NVIC_DIS0) = 0xffffffff;

HWREG(NVIC_DIS1) = 0xffffffff;

HWREG(NVIC_DIS2) = 0xffffffff;

HWREG(NVIC_DIS3) = 0xffffffff;

HWREG(NVIC_DIS4) = 0xffffffff;

SysTickIntDisable(); // disable the systick interrupt

SysTickDisable(); // stop the systick counter

 

USBDevDisconnect(USB0_BASE); // disable the USB device before the jump back to boot

 

ROM_UpdateEMAC(g_ui32SysClock); // Make the call jump to boot so we can download.

 

The question I have is does that indicate I have a problem lurking in my code that may cause a problem later or calling USBDevDisconnect(USB0_BASE); something I should be doing anyway before I jump to the boot if I am using USB?

 

Thanks,

Doug

I should add that I am using Code Composer Studio Version 6.1.2, TIRTOS 2.16.0.08, Compiler 5.2.7 and XDC tools 3.31.1333.

Doug