Boot loader behaviour on i.MX RT 1021

[mjbcswitzerland]

Hi All

I have two i.MX RT 1021 boards, one with Rev. A part and one with Rev. B part.

A. If I delete the QSPI content and boot with BOOT0 = '1' and BOOT1 = '0' both start in the internal boot loader (expected).

B. If I set Boot0 = '0' and Boot1 = '1 the behavior is different though:The Rev. A part starts in the boot loader but the Rev. B one doesn't. Due to the fact that there is no valid code found I would expect both to start in the boor loader.

Another difference in behavior is that in the B. state it is not possible to connect the debugger to the Rev. B part (but is is with the Rev. A part).

No eFUSEs have been changed.

Is this behavioral difference expected?

During the investigation there is a strange behavior of the NXP MCU Boot Utility v3.4.0 which is identical for both i.MX RT 1021 parts:
- initially there is code loaded in memory and that is seen by reading back with the tool. I show the memory area from 0x600001b0, which is filled mostly with zeros but also a 0x01, 0x10 and 0x80 can be seen:

Then I do an erase or a mass erase and read it again:

As expected the content is all 0xff since the QSPI flash was erased.
I can repeat the read and each time it is shown as erased.

Next I command Reset device and reconnect again and read the memory once more:

Now the first 512 byte are shown as programmed with something but not exactly the same, but nothing else is programmed in the reset of the memory.

Is this really being programmed by 'something' or is it an error with the NXP MCU Boot Utility when it reads?

Regards

Mark

[jeremyzhou]

Hi，
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Is this behavioral difference expected?
-- Of course, no. When the content of QSPI is empty, it will Serial Download even with the boot mode is Internal boot mode, can you use the NXP MCUBootUtility to contact the RevB under this condition?
2) Is this really being programmed by 'something' or is it an error with the NXP MCU Boot Utility when it reads?
-- The phenomenon is normal, as the NXP MCU Boot Utility will configure the external flash during establishing the connection.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------.

[mjbcswitzerland]

Hi

Many thanks for the responses:

1. I managed to solve the issue with the debugger not connecting.
I found that on the board with the B revision the Flash configuration jumper had been soldered incorrectly and was selecting hyper flash. This was not visible using either NXP MCU Boot Utility nor programming code with the debugger since the code read back was correct.
However, the processor was reading it in hyper flash mode and reads only 0x00.
The side effect of this is that (for some reasons) it stops the debugger from being able to connect, although setting the ISP mode then allows the debugger to operate.
Therefore the confusing and unexpected thing is that incorrectly setting the hyper flash configuration when QSPI flash is used renders the JTAG/SWD interface inoperable.Also the ISP mode is not entered, which is in contradiction to the expected behavior that if there is no valid code ISP is taken (and I would not expect the JTAG/SWD to also stop working)..
Therefore the behavior was indeed bizzare and confusing but now it is known  - "check the Flash config if such things happen".

2. I don't see why the MXP MCU Loader Utility would want to write a (partial (?)) header to the Flash on connection but it does explain what is seen. Thanks.

Regards

Mark

[mjbcswitzerland]

Hi All

I have attached a video showing the NXP MCU Boot Utility behavior.

Regards

Mark