MCF54415 Software Reset Failed

[leocheng]

I came accross a problem that software reset fails.

System board:

The board uses serial boot facility to boot up, there is a 16MB SPI flash connected to SBF pins, and also the DSPI0 is used to connect another device.

Symptoms:

Spftware reset failed sometimes, but /RSTOUT pin will also be asserted (from high to low level).

Troubleshooting:

I found there is a strange phenomenon, There is no problem and software reset is always OK if DSPI0 is never used(not communicate with the external SPI device), while software reset shall be failed sometimes if DSPI0 is used before.

[leocheng]

Thanks your replay. The details you asked are below:

1. software reset fails means: Boot code already has debug log and generate a special waveform on UART0_TXD,

    high        for 1 ms

    low         for 1 ms

    high        for 100 us

    low         for  200 us

    high        for 1 ms

When software reset fails, there is no debug log and no waveform, so the boot code is not running. But /RSTOUT pin is asserted although failed.

2. Now we use hardware reset(via external reset pin) as a workaround, it no problem, reset always works.

3. When you say "SDPI is used", have you used it to do only a few cycles, or has it been set up to continuously transfer to or from an external device?

Replay: use it to do only a few cycles. Software reset fails sometimes once DSPI_PUSHR register is written.

4. SPI DMA and interrupts are disabled

5. About reset SPI register, I already tested this, it's no useful.

    // Clear Tx FIFO

    MCF_DSPI0_MCR |= MCF_DSPI_MCR_CLR_TXF;

    // Clear Rx FIFO

    volatile uint8 temp;

    while (MCF_DSPI0_SR | MCF_DSPI_SR_RFDF)

    {

        temp = MCF_DSPI0_POPR;

        time_delay(5);      // wait 5us

    }

    // this way of clearing Rx FIFO doesn't work, can't exit while loop.

    //MCF_DSPI0_MCR |= MCF_DSPI_MCR_CLR_RXF;

    //while(MCF_DSPI0_SR | MCF_DSPI_SR_RFDF);

    // Reset spi registers

    MCF_DSPI0_MCR |= (MCF_DSPI_MCR_MDIS | MCF_DSPI_MCR_HALT);

    MCF_DSPI0_TCR = 0;

    MCF_DSPI0_CTAR0 = 0x78000000;

    MCF_DSPI0_CTAR1 = 0x78000000;

    MCF_DSPI0_CTAR2 = 0x78000000;

    MCF_DSPI0_CTAR3 = 0x78000000;

    MCF_DSPI0_CTAR4 = 0x78000000;

    MCF_DSPI0_CTAR5 = 0x78000000;

    MCF_DSPI0_CTAR6 = 0x78000000;

    MCF_DSPI0_CTAR7 = 0x78000000;

    MCF_DSPI0_SR = 0x9a0a0000; // Write 1 to clear

    MCF_DSPI0_RSER = 0;

    time_delay(200000);   // delay 200ms, Add this delay can reproduce the problem more easily

    MCF_RCM_RCR = MCF_RCM_RCR_SOFTRST;  // do software reset

[TomE · Accepted solution]

I still don't know where the boot code is running from. What is it loaded into? You haven't answered my question so I guess I'll have to read the SBF part of the manual to find out.

It shifts data in from the SPI port and (optionally) into SRAM. So it is executing code from there.

But the interesting part of your report is:

> But /RSTOUT pin is asserted although failed.

And from your first post:

> Spftware reset failed sometimes, but /RSTOUT pin will also be asserted (from high to low level).

I'm having to assume that means that /RSTOUT asserts LOW, and then STAYS LOW. Is that what you're seeing?

Have a look at "12.4.2.1 Non-SBF Reset Sequence". That's not what you're doing (but it might be), but that shows where in the flow chart /RSTOUT is asserted and deasserted. As long as your hardware is correctly driving the BOOTMOD pins, it should be following "12.4.2.2 SBF Reset Sequence".

The problem I have with the manual is that the latter chart doesn't say where /RSTOUT is deasserted. I'm assuming at the end of that flow chart.

Anyway, either the hardware isn't getting into that flowchart, or it isn't getting out of it. So what could be going wrong that is preventing exit, or at least preventing everything from going perfectly and ending up with code being read from FLASH into SRAM and then being executed? Quite a lot.

So check the BOOTMOD pins to make sure they're hardwired or pulled to the right state.

Check that the oscillator is still running properly. You may have a board fault where there's a short between the DSPI pins and something that is affecting the clock or crystal.

So assuming it is in the SBF flowchart, either the data it is reading from the external chip is corrupted or the clock is stopping somehow, possibly by a bad value read from SBF_RCON.

So you should use an oscilloscope, and record all of the early SBF pin transitions for a "good boot", and then repeat it for a "bad boot" and see if there are any differences.

You may have a board fault where the DSPI0 pins are affecting the SBF pins. Except I've just found the SBF pins ARE the DSPI0 pins.

The SBF also depends on the device connected to the SBF pins being in the correct (reset or idle) state to recognise the READ command send to it. If the FLASH chip was left partially clocked or in the middle of something when the reset happened it could explain the problem.

> delay 200ms, Add this delay can reproduce the problem more easily

That sounds like you've got a floating pin that should be pulled up or down. Maybe you need pullups on SBF_CS, SBF_CK or SBF_DO. They could be floating into intermediate states and getting the FLASH chip out of sync.

Hey, the SBF and DSPI0 share pins! If you've been accessing DSPI0 then it will certainly have been affecting the pins connecting to that other device. You certainly need pullups on DSPI0_PCS1/SBF_CS and DSPI0_PCS0/SS so that the other chip is guaranteed to not be selected during the boot.

The problem may be that "DSPI0 is used to connect another device." and that device may still be driving the DSPI0_SIN/SBF_DI pin after its cycles, driving against the first FLASH device.

An oscilloscope is the first thing to try to find which of the above might be happening.

Tom

[TomE]

When you say "software reset fails", that could mean "it doesn't reset at all, not even the external reset pin" all the way up to "my device didn't complete booting". Which is it (you said the external pin toggles)? How far along the reset process did it get? Did it START reading the Flash through the SBF pins? Did it start running that code? Does that code run from internal or external RAM? How far did that get? Can you have the boot code print to a UART or blink some LEDs to indicate progress?

An Oscilloscope on various pins should show how far it is getting.

Maybe the DMA controller associated with the SPI is doing something strange.

I'd suggest resetting the DSPI in different ways before attempting the Software Reset, and see if any one setting fixes the problem.

I'm looking at the MDIS, DIS_TXF, DIS_RXF, CLR_TXF, CLR_RXF and HALTbits in the DSPICn_MCR. You should write code to work on them one at a time and then see if the soft reset becomes reliable.

When you say "SDPI is used", have you used it to do only a few cycles, or has it been set up to continuously transfer to or from an external device?

If it is still running, then the problem may be that the CPU can't reset properly while a DMA cycle is currently running to external memory.

This is a common problem with these chips, but you usually find that an external hardware reset doesn't work if it happens during a memory cycle.

The CPU has a RESET pin on it, but check the data sheets and you'll find that DRAM chips don't have reset pins. If the CPU and DRAM controller resets part way through a memory cycle, then the DRAM chip doesn't know this, and may need to be "clocked out" of the middle of its current cycle before it can be read or written again. Worse, it may be driving the data bus and preventing anything else on the same data bus (like the boot ROM) from working. That doesn't seem to be your problem as you're using a Serial Boot, unless some part of the Boot that needs the external RAM is the part that is failing.

Tom