Writing to the QSPI Flash of i.MX RT1021 using write_image_win.bat

[takagi_y]

I am using write_image_win.bat to write to the QSPI Flash of i.MX RT1021.

However, writing to a brand new board fails.

The situation is as follows.

・When writing to a brand new board with a bat file, the process that displays "Erase memory before writing image" displays "failed".

・Boards that have already been written to with the SEC tool can be written to with the bat file.

This situation also occurs with i.MX RT1062 and MCXN947.

The following are the questions I would like to ask.

1. Why can't I write to a brand new board with a bat file?

2. Is there something I need to do to write to a brand new board with a bat file?

3. Is there a difference between a board that has already been written to with the SEC tool and a brand new board?

Please answer.

Best regards

[Gavin_Jia]

Hi @takagi_y ,

Thanks for your interest in NXP MIMXRT series!

When we burn image with the SEC tool, we need to make sure that the board is placed in serial download mode and it needs to match the board's flash.

Please first make sure that your new board is ready to burn image via the SEC tool after performing these preliminary steps.

Then, in the log window of the SEC tool, it points out all the underlying commands executed, and by analyzing them, you can even create your own *.bat scripts.

Best regards,
Gavin

[takagi_y]

Thank you for your reply.

The board mode is set to serial download mode.

The same Flash is used for the writable board and the new board.

After performing "Test connection" for USB and "Test the configuration" for "FlexSPI NOR - simplified" in the SEC tool, I closed the SEC tool, turned the board back on, and tried writing using the bat file, and writing was successful.

Does the USB and FlexSPI tests perform any processing on the board other than just checking the connection?

Also, is it correct to assume that the FlexSPI test performs the same processing as ext_memory_setup.bat?

If the processing is the same, does this mean that writing can be performed on a new board by running ext_memory_setup.bat and then write_image_win.bat?

Best regards

[Gavin_Jia · Accepted solution]

Hi @takagi_y ,

Yes, your understanding is correct.When executing the ext_memory_setup.bat, the point is to load the flashloader into RAM, and after that, any operations on the flash need to call the instructions in the flashloader.

If you still want to explore the details, it's a good idea to use MCUBootUtility, as it doesn't encapsulate any bat file at all, and what's shown in the log window is the full blhost command, fully exposed to the user.

Best regards,
Gavin

[takagi_y]

Thank you for your reply.

I also appreciate your advice.

Could you please explain a bit more about the need to read the flashloader into RAM?

If the power is turned off after the flashloader has been read into RAM, will the flashloader stored in RAM be erased?

If you run ext_memory_setup.bat once, you can write using write_image_win.bat even if you turn the power on and off.

Does this mean that by running ext_memory_setup.bat, the chip is set up so that the flashloader is read into RAM every time the power is turned on?

If so, is the setting something like Flash or something like eFuse?

Best regards

[Gavin_Jia]

Hi @takagi_y ,

If the power is turned off after the flashloader has been read into RAM, will the flashloader stored in RAM be erased?

If you run ext_memory_setup.bat once, you can write using write_image_win.bat even if you turn the power on and off.

After the board is powered down and rebooted, the flashloader running in RAM will disappear, but the step write image will be executed to check the running status of the flashloader, and if it is not running, it will reload the flashloader, which is executed by calling init_flashloader_win.bat. 

You can see the overall flow by deleting the logs in the logs folder, then re-powering up the board and executing only the write image, and then checking the logs file.

To be precise, SEC generates a lot of scripts and corresponding flashloader in this step of testing connection, and these scripts may also call others later.

Best regards,
Gavin