TM4C129ENCPDT: impact of reset by reset pin vs. software-initiated reset or watchdog reset on SSI port

Hi Tianlei,

When you said software reset, did you mean software system reset request using the SYSRESREQ bit in the APINT register? The software reset (by calling SysCtlReset) is supposed to reset the much of device including the core and the peripherals. Or did you do a software Peripheral Reset using SysCtlPeripheralReset() API? If you use SysCtlPeripheralReset on the SSI then only the SSI is reset and nothing else. Let's suppose the pin muxing logic is at fault then a SysCtlPeripheralReset on the SSI will not reset the muxing logic. You will need to call SysCtlPeripheralReset to reset the GPIO pin muxing logic.

I'm also surprised a WD reset does not reset the device. The WD reset is again supposed to reset pretty much the entire device depending if you configure the WD timeout event to trigger either a power-on reset or a system reset. This is programmable.

In any case, have you tried with a different MCU chip? Can you repeat the same problem? If you can repeat the same problem with different chips or boards then it is most likely a software issue. I will suggest you use a scope to Logic Analyzer to see what is the state of the SPI bus when the it is in non-functional state.

Hi Charles,

Thanks for your reply.

To clarify, software reset means calling SysCtlReset().

So far, my understanding is that  watchdog reset should have the same effect as reset-pin,right?

I am going to do more experiment on this as you suggested and update this thread later.

Tianlei

Hi Tianlei,
Yes, the WD should act like a reset pin to reset the device. Let's us know your updates.

Hi Charles,

First let me make a correction of the MCU type. It is actually LM3S9790. We have switched to TM4C129ENCPDT in our newer design, but the problem observed was on the older board.

We did a few more experiments, and it was confirmed that the MCU was stuck in some state that can only be brought back by Power Reset or External Reset Pin. Under such state, it seems that the only working part of the MCU is the Ethernet port (we use Ethernet protocol to communicate with the MCU and everything looks fine). We are using 2 SSI ports, one for external flash and one for audio CODEC. They are both not functioning.

Through Ethernet protocol, we can command the device to have a Watchdog Reset or Software-initialed Reset, we can observe the reset through Ethernet log messages, but the device would still go to the faulty state after boot.

The flash port initialization procedure won't return a success from the beginning:

tBoolean
SSIFlashInit(void)
{
    tBoolean bRetcode;
    unsigned char ucManufacturer, ucDevice;

    //
    // Enable the peripherals used to drive the SDC on SSI.
    //
    SysCtlPeripheralEnable(SFLASH_SSI_PERIPH);
    SysCtlPeripheralEnable(SFLASH_SSI_GPIO_PERIPH);

    GPIOPinConfigure(SFLASH_SSI_CLK_MUX);
    GPIOPinConfigure(SFLASH_SSI_RX_MUX);
    GPIOPinConfigure(SFLASH_SSI_TX_MUX);

    //
    // Configure the appropriate pins to be SSI instead of GPIO. The CS
    // is configured as GPIO since this board has 2 devices connected to
    // SSI0 and each uses a separate CS.
    //
    GPIOPinTypeSSI(SFLASH_SSI_GPIO_BASE, SFLASH_SSI_PINS);
    GPIOPinTypeGPIOOutput(SFLASH_CS_BASE, SFLASH_CS_PIN);
    GPIOPadConfigSet(SFLASH_SSI_GPIO_BASE, SFLASH_SSI_PINS, GPIO_STRENGTH_4MA,
                     GPIO_PIN_TYPE_STD_WPU);
    GPIOPadConfigSet(SFLASH_CS_BASE, SFLASH_CS_PIN, GPIO_STRENGTH_4MA,
                     GPIO_PIN_TYPE_STD_WPU);

    //
    // Deassert the SSI0 chip selects for both the SD card and serial flash
    //
    GPIOPinWrite(SFLASH_CS_BASE, SFLASH_CS_PIN, SFLASH_CS_PIN);

    //
    // Configure the SSI0 port for 10MHz operation
    //
    SSIConfigSetExpClk(SFLASH_SSI_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,
                       SSI_MODE_MASTER, 10000000, 8);
    SSIEnable(SFLASH_SSI_BASE);

    //
    // Wait for the device to be ready to receive an instruction.
    //
    bRetcode = SSIFlashIdleWait(MAX_BUSY_POLL_IDLE);

    //
    // If the device didn't report that it was idle, assume it isn't there
    // and return an error.
    //
    if(!bRetcode)
    {
        return(bRetcode);
    }

        return(1);
}

We even tried to invoke this procedure via Ethernet protocol, it did not help and also returned a failure.

The problem has happened on a few devices on customer sites. The symptom is exactly the same as the one in our lab by static shock.

It will be very helpful if there is a method that can programmatically cause the MCU a deep reset. That will solve our problem.

Thanks,

Tianlei

Tianlei,
The LM3S is NRND. I'm also not familiar with this old device. I will suggest you look at the SSI port on the scope. Do you see proper SPICLK and MOSI/MISO behavior. It seems like the error depends on the returned value of SSIFlashIdleWait. What does SSIFlashIdleWait do? Are you expecting to receive some data from the external flash device? If the MCU is sending the proper command then you might want to investigate why the flash device doesn't return data. If the MCU doesn't send any commands on the SSI interface then the problem is on the MCU side.

As I mentioned before the software system reset or WD reset is supposed to reset the device. Your best choice would be the software system reset. In your software reset handler can you try to first reset the SSI and then re-initialize it?