I have a curious problem:
I'm using a NAND-Flash via FlexSPI in parallel to a NOR-Flash.
(A)
It works fine when i
1. download the program via the MCUXpresso IDE GUI Flash Tool (without reset) using the standard NOR-flash driver.
2. then i force a POR via pulling the POR_B pin to ground manually.
(B)
If i power cycle the device and then force a POR the NAND-Flash doesn't work anymore.
So i'm wondering what the difference between the 2 versions of reset might be. In both cases i force a POR which should, as i understand it, reset all SoC modules.
One obvious difference is that the NOR-flash driver isn't loaded in case (B). But whatever the driver does, it shouldn't survive the POR.
Maybe someone has an idea, what the problem might be.
Kind regards,
Johann
Solved! Go to Solution.
I could finally figure out the problem.
The flash driver (MIMXRT1050-EVK_IS25WP064A) has 13 LUT entries (array indices 0 - 49) but sets CUSTOM_LUT_LENGTH to 60.
So it initializes array indizes 50 - 59 with 0 when calling FLEXSPI_UpdateLUT().
In my program i have 15 LUT entries. In the last entry (#14) i did only set 2 array inices: 56 and 57 but i
didn't set array indices 58 and 59 to 0. So those 2 array indices seemed to have some undefied value.
After loading the program with the driver, array indices 58 and 59 were set to 0 by the driver code (even after triggering a POR) but when i turned the supply off and on again, they would have some undefined value causing the corresponding NAND-flash command to fail.
So the lesson to take away here is:
Because 1 LUT entry is 4 array indices in C-code and a typical setting in the code looks something like this:
[4 * NAND_LUT_READ_STATUS_REG] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05,
kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x08),
[4 * NAND_LUT_READ_STATUS_REG + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x01,
kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0),
you have to make sure that the remaining array indices (4 * NAND_LUT_READ_STATUS_REG + 3 and 4 * NAND_LUT_READ_STATUS_REG + 4 in this example) are set to 0.
Hello Sabina,
with power cycling i mean turning off the supply voltage and turning it on again.
In contrast to that is trigger a POR pulling the POR_B pin to ground (while my board is still supplied).
For flashing the program i use the
MIMXRT1050-EVK_IS25WP064A LinkServer/CMSIS-DAP Flash Driver
with some minor modifications for my QSPI NOR-Flash from ISSI (IS25WP256D).
I use the
NOR-Flash on port A1 of the FlexSPI interface and a
NAND-Flash from Winbond (W25N01GVZEIGIT) on port B1.
Everything works fine when i
- debug the program
- flash the program with the GUI Flash Tool (MCUXpresso - Blue Button) without debugger
in those 2 cases i can also reset the device with a POR and everything is still fine.
But when i turn the power off and on again something is different.
What i figured out so far is after the FlexSPI initialization when i first try to communicate with the NAND flash,
more precisely in fsl_flexspi.c in function
FLEXSPI_TransferBlocking, when the command is triggered with
base->IPCMD |= FLEXSPI_IPCMD_TRG_MASK; // here the pins should wiggle
there is nothing happening on the FlexSPI interface (no Chip Select, no Clk, etc.).
In the working case exactly at the same position i can see a communication with the NAND-flash.
The related command looks like this in the LUT
[4 * NAND_LUT_READ_STATUS_REG] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05,
kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x08),
[4 * NAND_LUT_READ_STATUS_REG + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x01,
kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0),
so i try to read the status register of the NAND-flash.
It seems that the FlexSPI - Interface is not starting the communication.
What really puzzles me is that it's working in the one case and not in the other.
I can only conjecture that it has to do with the flash driver. Thats the only real difference i see.
Maybe some settings from the driver survive the POR.
I checked the driver code but haven't found anything yet.
Thank you and sorry for the lenghty post,
Johann
I could finally figure out the problem.
The flash driver (MIMXRT1050-EVK_IS25WP064A) has 13 LUT entries (array indices 0 - 49) but sets CUSTOM_LUT_LENGTH to 60.
So it initializes array indizes 50 - 59 with 0 when calling FLEXSPI_UpdateLUT().
In my program i have 15 LUT entries. In the last entry (#14) i did only set 2 array inices: 56 and 57 but i
didn't set array indices 58 and 59 to 0. So those 2 array indices seemed to have some undefied value.
After loading the program with the driver, array indices 58 and 59 were set to 0 by the driver code (even after triggering a POR) but when i turned the supply off and on again, they would have some undefined value causing the corresponding NAND-flash command to fail.
So the lesson to take away here is:
Because 1 LUT entry is 4 array indices in C-code and a typical setting in the code looks something like this:
[4 * NAND_LUT_READ_STATUS_REG] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05,
kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x08),
[4 * NAND_LUT_READ_STATUS_REG + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x01,
kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0),
you have to make sure that the remaining array indices (4 * NAND_LUT_READ_STATUS_REG + 3 and 4 * NAND_LUT_READ_STATUS_REG + 4 in this example) are set to 0.
I am glad you were able to resolve this!
Thank you for sharing the resolution.
Best Regards,
Sabina
Hello Johann,
Hope you are doing well.
I'd like to better understand what it is exactly that you are doing. If possible, could you please describe how you are power cycling, to me power cycle and POR are the same. Do you have the same behavior occur in debug session, so after the program is flashed it and reset using the debugger?
Best Regards,
Sabina
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------