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.

MSP432E401Y: Ethernet init timeout (cable not plugged in) causes flash prefetch to be temporarily disabled ~10mins after boot

Part Number: MSP432E401Y

Hello TI,

Our MSP432E401Y application has a zero latency interrupt that consumes around 50% of the processing capability.

When the flash prefetch is turned off this grows to exceed 100% of processor time which starves the RTOS completely, so it is unable to turn flash prefetch back on.

Syscfg autogenerates ti_ndk_config.c which looks to try to restart the network stack when it fails:

    /*  Boot the system using this configuration
     *
     *  Loop until the function returns 0. This facilitates a reboot command.
     */
    do
    {
        rc = NC_NetStart(hCfg, NULL, NULL, netIPAddrHook);

        /* user reboot hook == null */

    } while (rc > 0);

This eventually calls EMACMSP432E.c:

static int EMACMSP432E4_emacStart(struct NETIF_DEVICE* ptr_net_device)
{
    ...

    key = HwiP_disable();

    /*
     *  This is a work-around for the EMAC initialization issue found
     *  on the TM4C129 devices. This can be found in the silicon errata
     *  documentation spmz850g.pdf as ETH#02.
     *
     *  The following disables the flash pre-fetch (if it is not already
     *  disabled).
     */
    ui32FlashConf = FLASH_CTRL->CONF;
    if ((ui32FlashConf & (FLASH_CONF_FPFOFF)) == false) {
        enablePrefetch = true;
        ui32FlashConf &= ~(FLASH_CONF_FPFON);
        ui32FlashConf |= FLASH_CONF_FPFOFF;
        FLASH_CTRL->CONF = ui32FlashConf;
    }

    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_CONFIG);
    
    ...
}

I can't see a way out of the flash prefetch being turned off using current NDK and Syscfg.

As far as I can imagine, my only chance of a workaround is run the zero-latency interrupt from RAM. Is execution from RAM as quick as prefetched Flash?

Can you provide a solution here that either does not trigger the flash prefetch being disabled?

Thanks.

  • Hi,

     Sorry, I'm currently on vacation for the rest of the week without access to my PC to read the source file. I think the flash prefetch should be re-enabled again after the initialization. Can you please check the register in the register browser? Is it  disabled and not enabled again? 

      Although it's possible to run code out of RAM, we should understand why the flash prefetch is not enabled. Yes, RAM is a single cycle access memory at 120Mhz.

  • Yes it does turn the prefetch back on. Unfortunately, our Zero Latency interrupt (when running from flash with prefetch turned off) consumes all processor time, so the rtos does not have the chance to turn it back on. Regardless, our application has fallen over at this point. We use around 11us out of every 23us. Disabling prefetch slows this down around 2.7 times.

    For anyone interested, running from ram is especially easy: just add "__attribute__((ramfunc)) " prior to "void MyInterrupt(void){". You might need to add "    .binit  :   > FLASH" to your linker file. This has fixed our immediate problem.

    I agree, the why in turning prefetch off is important.This post https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/916178/msp432e401y-does-errata-eth-02-exist-in-msp432e-devices asks this question, but had no answer. Maybe it was in the wiki?

    Imagining again, I've come up with the Ethernet peripheral setup is done by DMA, and it writes too quickly for the peripheral. In this case, the ram workaround works in that the DMA is still slow fetching stuff from flash, but our interrupt runs full speed.

    If however, the peripheral needs stuff DMAed quickly from RAM and turning prefetch off is a way to get bus time from the CPU, the ram workaround will break it. We're ok with that because the user is able to power cycle at their convenience to get the ethernet port going again, rather than our device crashing every 10 minutes.

    This would get really silly if it turns out that executing anything from RAM could break Ethernet functionality.