Problem with reset when using SEMC SDRAM and NAND on iMXRT1176

[DrJonM]

Hi, 

We have a custom board (though layout very similar to EVK) with SDRAM and NAND connected to SEMC and NOR flash connected to FlexSPI.

System boots CM7 from NOR with XiP and loads DCD to configure SDRAM (on SEMC CS0). Boot loader stack is in SDRAM. Boot loader then copies application from NOR to SDRAM and jumps to application to continue executing from SDRAM. This all woks as expected.

We also have NAND connected to SEMC CSX0 for additional storage. This may be initialised in the boot code or the application. NAND access works well and does not intefere with SDRAM.

Now the problem - after in system programming (when running  either boot or application) the system issues a reset (currently via SCB_AIRCR though I have also tried SRC->CTRL_M7CORE = 1). 

If the NAND has not been initialised, this works perfectly - the system restarts the ROM boot, DCD is loaded and boot code is run.

However, if the NAND has been initialised, the process fails. The micro resets and (looking at the SEMC registers) the DCD is loaded correctly - all SEMC registers are at their default values except for those configured by DCD. But the code hard faults on accessing the stack. Oddly, the SDRAM appears to be functional though - if I load some test code into OCRAM, I can read and write the SDRAM no problem without any further configuration.

However, it doesn't matter how many times I do a software reset at this point (even without re-initialising the NAND), the device won't boot. A power cycle however, does reboot the unit succesfully.

The problem appears to be triggered by sending an IP command to the NAND. If I just initialise the SEMC with the NAND parameters, no problem occurs but after the first IP command in semc_nand_issure_reset, the beahviour described above occurs.

What would cause the device to not restart cleanly after a software reset and why would this occur after an IP command in NAND space?

I have not yet tried configuring the NAND in the DCD as I would like to keep some flexibility for changing NAND parts in the future. Is this necessary though?

Thanks,

Jon

[jingpan]

Hi @DrJonM ,

It sounds to me like the NAND initialization code located in SDRAM. When it send NAND IP command, the system fault. Since SDRAM and NAND are both interface to SEMC, can you try to move the NAND IP command trig function to OCRAM?

Regards,

Jing

[DrJonM]

Hi @jingpan Jing,

NAND init code (for the boot code at least) is based in NOR and NAND structures in OCRAM.

To prove the point though, I have written a program that is all in OCRAM; DCD and boot code is run from NOR by ROM boot which configures SDRAM. This version of boot code does not configure NAND.

I then program test code into OCRAM with debugger. Test code is very simple, essentially:

    NAND_init();
    SEMC_SDRAMTestAll8();
    __disable_irq();
    SCB_DisableDCache();
    SCB_DisableICache();

    for (volatile int n = 0; n < 100000000; n++)
    {
        __asm("nop");
    }
    SCB->AIRCR = (0x5FA << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk;
    while (1)
    {
    }

NAND_init() calls the SDK Nand_flash_init function to initalise the SEMC for NAND and get the ONFI information from the NAND chip.

SEMC_SDRAM_TestAll8() just writes and verifies an 8 bit test pattern to SDRAM and is relying on SEMC being set up by DCD in boot code.

If NAND_init is commented out, Code runs, tests SDRAM and finally resets the micro back into boot code.I can run this many times, no problem.

If NAND_init is not commented out, code runs, tests SDRAM succesfully and resets the micro, but the boot loader hard faults during stack initialisation. Trying to run again with NAND_init commented out also fails; the only way to recover is to power cycle system.

Thanks,

Jon

[jingpan]

Hi @DrJonM ,

You said that the bootloader stack is in SDRAM. In SEMC_ConfigNAND() it will stop SEMC until config finish, during this period bootloader push/pop operation will cause hardfault.

Regards,

Jing

[DrJonM · Accepted solution]

Hi @jingpan 

I have found the problem - the NAND CS was incorrectly configured with a pulldown. It seems that once written to, the NAND chip is able to load the bus when the CS is low. This was not a problem when the device was running as SEMC was driving SDRAM and NAND CS but once unit reset, the CS would be low and the NAND would prevent the SDRAM from working during startup so the boot loader would fail to load. Only a power cycle to reset the NAND would resolve.

Now NAND CS is correctly configured with a pullup, the system behaves as expected.

Thanks for your help,

Jon