i.MX RT 1020-1015 version mismatch

[albertobattistello]

Hello, I am having a doubt about the MCUXpresso Secure Provisioning tool (V 3.1).

I own a MIMXRT1020-EVK board, which provides the PIMXRT1021DAG5A chip. On the board, the string "170-29856_REV A2" is engraved.

I connect the board to the MCUXpresso Secure Provisioning tool using the UART interface and I select the configuration for the MIMXRT1020. However, the FlashLoader does not start and the communication is not available, thus the commands (such as showing the OTP configuration) fail.

Then, I connect the board using the USB interface, the tool detects my IMXRT1020 as a IMXRT1015. If I configure the workspace for a 1015, the FlashLoader works correctly and I can see the OTP settings.

I am wondering if this board mismatch is related to an hardware or a software issue. Moreover, is it safe to burn the fuses and activate the secure boot using the workspace for the 1015 board? Did I miss something?

Best Regards

[diego_charles]

Hi @albertobattistello 

Thank you for posting your inquiries. Let me give you my current observations.

My background : 

I have a board with the Schematic REV B1 and version 700-29856 RevB1, which is  newer. My board also has PIMXRT1021DAG5A. 

The P means, according to the DS, that our boards have prototype chips and the A that we have the Rev0A.

I am also using Secure provisioning tool v3.1,  in my case windows 10.

My test:

1. The SP was  able to detect the MCU as RT1020 by UART and, like you reported it detected the MCU as RT1015 by USB. Unfortunately I was not able to replicate this issue again,  it just happened the first time.

2 Then I created a new workspace  and proceed to test UART, then  I did a POR the board, and change test to USB. In both cases the SP detected my RT1020 as  RT1020.

3. Current comments. 

Simple question > If you power cycle the board and the use another workspace do you still get this issue? 

Unless our chips have any other difference,  it seems like a SW issue but I am  checking further on this and your last question. 

Many thanks for your patience.

Diego

[albertobattistello]

Hello,

Thanks Diego for your response. After the power cycle and the first connection the board is recognized as expected by the MCU Secure Provisioning tool.

Even though it seems to be a software issue, do you think it is safe to burn OTP?

Regards.

Alberto

[diego_charles]

Hi @albertobattistello 

Thank you for letting me know your results!

If you are able to see corresponding OTP configuration for the I.MX RT1020, you should be safe to burn OTP settings.

Best regards, 

Diego