RT1166 octal-SPI issue (erase doesn't work).

[aleksejshch]

Hi! I'm working on bring-up of custom boards based on RT1166. I have MIMXRT1160-EVK board also.
Our custom boards has octal-SPI flash MX25UM25645GXDI00. Flash connection to MCU uses same pins as on EVK.
I tried to reproduce steps from topic "RT1170 Octal flash enablement" (https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT1170-Octal-flash-enablement/ta-p/1498369), but looks like something wrong with flash.
I have 2 our custom boards, so I can reproduce same behavior on both.

Previous work with custom boards includes code execution from RAM, and it works. As debugger I use J-Trace Cortex-M.
Sure, firstly I modified EVK board to use octal-SPI flash, and there no problems with EVK as expected.

Below I describe steps on our custom board:
1. Setup fsl_romapi example to execute from RAM, configured Flash_RST pin. And I see logs as in topic, without errors:

but in debugging I see one strange thing: in the end of code block after erasing in memory monitor I can see that erased bock wasn't erase, it is filled by counter:

And when I re-run debugging, and stop after first erase (before filling) I can see the same counter content in flash. So, looks like erase doesn't work. How is it possible and where might be mistake?

2. Anyway I continue with next way, JLINK Flashloader with RT-UFL (at this point I skiped MCUBootUtility as we have no UART1 required for it, and these pins used for another peripherals).
So, for this test I used old JLlik utility version, as in topic, JLINKV768B.
Here I tried to modify source and build RT-UFL Flashloader in Keil, but it can't be built. So, I used pre-built one from archive in topic ("RT1170 octal flash enablement sw.zip" -> RT-UFL/iMXRT_UFL/MIMXRT_FLEXSPI_UV5_UFL.FLM).
In JFlash I can connect to device and read flash (or write). But data which I read back is another than I written before:

If I try to erase then I can see next error:

If I re-connect power and try to erase chip, It responds success, but too quickly - less than 1s, while I expected > 2 minutes.

Note: boot pins configured to Serial Downloader.

3. For next test I used CMSIS-DAP debugger from EVK connected to our custom board. There I modified Flashloader source (re-write configuration for my flash_reset pin) and build, then attached to test project custom *.cfx file. And try to debug test project. Here I receive this error:

Note: boot pins configured to Serial Downloader.

4. Then I attached UART1 pins to external USB-UART bridge to use with NXP-MCUBootUtility. For first test I used same version as in topic, v3.5.0. And tested both EVK and custom board. Configured device model - Macronix_MX25UM51345G. On EVK works erase-write/read. While on custom board only read works, and I see the same data as in prev. tests:

Erase failed:

BT_CFG pins on custom board:

BOOT_CFG1[0] - 1,
BOOT_CFG1[1] - 0,
BOOT_CFG1[2] - 1,
BOOT_CFG1[3] - 0,
BOOT_CFG1[4] - 0,
BOOT_CFG1[5] - 0,
BOOT_CFG1[6] - 0,
BOOT_CFG1[7] - 0,
BOOT_CFG2[0] - 0,
BOOT_CFG2[1] - 0,
BOOT_CFG2[2] - 0,
BOOT_CFG2[3] - 0.

BT_CFG pins on EVK:
BOOT_CFG1[0] - 0,
BOOT_CFG1[1] - 0,
BOOT_CFG1[2] - 1,
BOOT_CFG1[3] - 0,
BOOT_CFG1[4] - 0,
BOOT_CFG1[5] - 0,
BOOT_CFG1[6] - 0,
BOOT_CFG1[7] - 0,
BOOT_CFG2[0] - 0,
BOOT_CFG2[1] - 0,
BOOT_CFG2[2] - 0,
BOOT_CFG2[3] - 0.

Then I tried more new versions of NXP-MCUBootUtility with EVK. But I see such error:

Such behavior on versions: 4.0.0, 5.3.2, 6.2.0. I tried to play with boot config switch, but anyway see such error.
It works only in v3.4.0.

So, I have next questions:
* What is wrong with flash erase on custom boards?
* Why NXP-MCUBootUtility > 3.4.0 doesn't work on EVK?

[kerryzhou]

Hi @aleksejshch ,

  Thank you for your interest in the NXP MIMXRT product, I would like to provide service for you.

Answer your questions:

1. Setup fsl_romapi example to execute from RAM, in the end of code block after erasing in memory monitor I can see that erased bock wasn't erase, it is filled by counter:

=>Answer: Do you also try the chip erase, whether that can erase all the memory.

Do you calculate the address, whether your checked area is really what your erased area block?

Do you also try the NXP MIMXRT1160-EVK with octal flash(need hardware modification), wehther that works or not?

2. JLINK Flashloader with RT-UFL

=>Answer: I think you need to generate the RT-UFL for the RT1160, instead of using the RT1170.flm, BTW, your read out memory have difference with the write memory, it is reasonable, it is caused by the JLINK download method.

I think, your mentioned difference is just the FCB difference, not the app area, right?

As the flashloader will help you generate the FCB and download it, that why it cause the difference of FCB, and I also report to RT-UFL author previous, he will help to fix this point, you don't need to care about it, if your app boots OK.

If you use the debugger, boot mode use the internal boot mode instead of the serial download mode.

3. For next test I used CMSIS-DAP debugger from EVK connected to our custom board. There I modified Flashloader source (re-write configuration for my flash_reset pin) and build, then attached to test project custom *.cfx file. And try to debug test project. Here I receive this error:

=>Answer: your log means your CMSIS DAP .cfx still have issues, your modification is not successful. Still need to check the flashloader for the .cfx.

4. Then I attached UART1 pins to external USB-UART bridge to use with NXP-MCUBootUtility.

=>Answer: use the NXP EVK board, USB interface instead of the UART, whether still have this issues? You need to select the correct octal flash partnumber.

Your customer board is the same octal flash, share your partnumber, thanks.

* What is wrong with flash erase on custom boards?

=>Answer: need to know your flash partnumber, as need the related option for octal flash.

* Why NXP-MCUBootUtility > 3.4.0 doesn't work on EVK?

=>Answer: EVK also have this issues?

EVK whether you do all the related hardware configuration for the octal flash.

Best Regards,

Kerry

[aleksejshch]

Thanks @kerryzhou for your support.

1. Yes, I modified HW on EVK for octal-SPI flash. I added full chip erase at the end of code block, and after full chip erase added breakpoint.

On EVK it works, I can check it in memory monitor window, and I waited a few minutes for the chip to be completely erased (as expected from flash datasheet):

Then I try to do the same on custom board. In log console no errors, but it took less than 1 sec to completely erase the chip. And in memory monitor I can see that memory is not empty:

2. I suggest to put this method on hold for now, as it looks the most complicated. I don't understand yet what I need to modify in the RT_UFL source code and how to build it to get a suitable *.flm for RT1160 with used flash memory.
Yes, I realized that RT_UFL writes the generated FCB. But as for the memory area with the application, it looks like it was written over previous test applications without pre-erasing. Because I have tried writing different test applications before. But this is just an assumption, I can't be sure of it.

3. What else should I change in the Flashloader code besides the GPIO used to reset the flash memory? I've checked with an oscilloscope, and I can see the flash_reset GPIO sequence when debugging starts. Right after that the error appears as in the screenshot I posted earlier. I built Flashloader as described in readme file: firstly build LPCXFlashDriverLib with configuration "Release_SectorHashing", then build iMXRT117x_FlexSPI_SFDP with configuration "MIMXRT1160_SFDP_MXIC_OPI".

4. I just checked USB instead of UART on EVK for Serial Downloader mode. Used MCUBootUtility version: v6.0.2.

Tried next device models:

- Macronix_OctalSPI_MX25UMxxx45G_MX66UMxxx45G_MX25LMxxx45

- Macronix_OctalSPI_MX25UM5134545G_MX25UW51345G

- Macronix_OctalSPI_MX25UM5134545G_Def_OPI_DDR

On EVK I set next boot config (as on silkscreen' scheme):

And anyway I can see same error: "MCU has entered Flashloader but failed to configure external memory. Please reset board and set proper boot device then try again".

Do I need to modify something in "Device Model" window? 

Flash part number used in our custom board: 

* need to know your flash partnumber, as need the related option for octal flash.

Answer => MX25UM25645GXDI00

* EVK also have this issues?

Answer => yes, this issue on EVK. I think I verified all HW changes for octal-SPI flash on EVK as it works with modified fsl_romapi example, and I can upload blink app, reset board and LED blinks. 

Is there anything else I can clarify or describe about my tests to make it easier for you to help me? Thanks.

[kerryzhou]

Hi @aleksejshch ,

  I think I know your issue root reason.

  Your used chip is MX25UM25645GXDI00, that is not the same as EVK on board MX25UM51345GXDI00, the sequence have difference, as you know, even the 513 also have two chips:

The read out data sequence have difference.

Maybe you can find one MX25UM51345G to test it.

This is the MX25UM51345G

This is MX25UM25645GXDI00

You can see the data have data sequence difference.

That's why your EVK works, but your own board can't work.

Best Regards,

Kerry

[aleksejshch]

Hi @kerryzhou . OMG, I compared datasheets for both flash chips before, but haven't seen this difference. It's hard to spot a little thing like that. I probably should used some diff tool.

Unfortunately, I can't find the MX25UM51345G on sale on either Digikey or Mouser. And I'm afraid to replace flash chip from EVK to our custom board. So I should to get our custom board  work with MX25UM25645GXDI00.

I have now found that the same difference in order of data bytes is present in other commands:

• Figure 43. OCTA Read Mode Sequence (DTR-OPI Mode)
• Figure 44. OCTA Read Mode Sequence (DTR-OPI Mode) with DQS pre-cycle enabled (CR2 DQSPRC=1)
• Figure 51. Fast Boot Sequence (DTR-OPI Mode)
• Figure 72. Page Program (PP) Sequence (DTR-OPI Mode)
• Figure 103. Read Password Register (RDPASS) Sequence (DTR-OPI Mode)
• Figure 106. Write Password Register (WRPASS) Sequence (DTR-OPI Mode)
• Figure 109. Password Unlock (PASSULK) (DTR-OPI Mode)
• Figure 119. Read Serial Flash Discoverable Parameter (RDSFDP) Sequence (DTR-OPI Mode)
• Figure 126. CRC Timing (RDPASS)
• Figure 127. CRC Timing (WRPASS/PASSULK)
• Figure 128. CRC Timing (WRFBR)

But most of them will not be used in LUT as I understand. We need "read" and "page program". 

So, I just repeated test (1) - modified fsl_romapi example to execute from RAM, configured Flash_RST pin, on custom board. There I added just one modification:

Set "data order swapped" flag:

norConfig.isDataOrderSwapped = 1;

before ROM_FLEXSPI_NorFlash_Init().

But in this case, the program behaves the same way. I don't see the chip being erased either (I'm looking in Memory Monitor in debug mode). The ROM_FLEXSPI_NorFlash_EraseAll() call is executed immediately (and returns success) instead of expected 75...150 seconds.

Do you think I might have missed something?

[kerryzhou · Accepted solution]

Hi @aleksejshch ,

  You can refer to this blog, which is write by our expert, it is using the chip like you:

https://www.cnblogs.com/henjay724/p/15880374.html

it hasthe resolution.

Wish it helps you!

Best Regards,

Kerry

[aleksejshch]

Hi @kerryzhou ! Thank you! Looks like exactly what we need. Thank you very much. Now I need some time to learn it and try it out.

Thanks!

[kerryzhou]

Hi @aleksejshch ,

  You are always welcome!

  If you meet any issues in the future, welcome to create the new case.

  We are always working with you when you meet NXP product issues.

Best Regards,

Kerry