Lost connection with IMXRT685-EVK

[slawek_zabielsk]

Hi,

I am preparing an image file to boot from the QSPIFlash memory (for dsp+cm33). To start with, I wanted to check the example gpio_led_output. I generated a BIN file. I uploaded the BIN file using NXP-MCUBootUtility.exe tool. The program started correctly. In the next approach I wanted to combine image file cm3 and dsp. For this purpose I used sample project hello_world_usart from SDK. I prepared a BIN file for dsp and cm33. I combined them elftosb. I loaded the BIN file with 0x1000 offset using NXP-MCUBootUtility.exe tool. However, the program did not start. In AN12751 I found a suggestion to set CFG[0] to 4b'0111/4b'1011/4b'1100/4b'1101/4b'1110. Fuse CFG[0] could be set to this value. The program still has not started. Attempting to restore CFG[0] to 0 ended up being unable to communicate with the USB interface from NXP-MCUBootUtility.exe. In addition, it is not able to start debug mode or upload any program using the JLINK2 connection. What did I do wrong? How can I return a connection to IMXRT685-EVK? Please help me.

Best Regards,

Slawek

[victorjimenez]

Hello Slawek, 

Based on the information that you provided it seems that you modify the CFG[0] fuse to some of the values mentioned in the application note AN12751. Later on, you tried to restore the default values on the CFG[0] fuses, correct? Which value do you have right now in these fuses?

The first important thing to mention here is that once you burn a fuse you cannot restore it to its default values, there's no turning back once you do this. So, if you did burn the fuses, you will have to see which value did you left on these fuses and see to which boot mode it corresponds. To see the primary boot source based on BOOT_CFG bits please refer to Table 973 of the user manual. 

Regards,

Victor 

[slawek_zabielsk]

Hi Victor,

Don't ask me why, but I left the value on CFG(90)=0x0007BCDF (I had CFG(0)=0x0007BCDE before). Then I lost connection.

Is there any way to fix this?

Best Regards,

Slawek

[slawek_zabielsk]

Hi again,

I looked at the user manual, Table 973. I wrote my values to the table. They should be like that (in red):

Am I correct?

Best Regards,

Slawek

[slawek_zabielsk]

Hi Victor,

However, I don't think this is Table 973. According to the user manual UM11147 BOOT_CFG[0] with the address 0x180, my cfg(0), is defined in "OTP Fuse Map for User Manual.xls" Excel sheet. If I am wrong, please say so. But if I'm not mistaken, and I wrote in BOOT_CFG[0] = 0x0007BCDF it means that:
PRIMARY_BOOT_src=0xF - reserved (I don't know what it means to be reserved)

DEFAULT_ISP_MODE=0x5 - reserved (I don't know what it means to be reserved)

BOOT_CLK_SPEED=0x1 - HISPEED_CLK

RSA4KEN=0x1 - use RSA4K

TZM_IMAGE_TYPE=0x1 - TZM_DISABLE

PSA_BSTATE_SKIP=0x1 - ROM skips computation of boot state

PSA_BSTATE_INC_KEYS=0x1 - boot state computation includes OTP shadow regs

REDUNDANT_SPI_PORT=0x7 - FC7

The rest of the bits are zero, no change.

Is there a way out of this situation? Is there any way to start a bootloader with my code on the devboard in order to continue development work. I am in the middle of working on the code, I have no way of testing it. Without the devboard it will be difficult for me to finish this work.

[victorjimenez · Accepted solution]

Hello Slawek,

Unfortunately, there isn't any way to undo the changes that you made in the BOOT_CFG[0] fuses. Once you burn a fuse, there isn't any way to turn this back. As you mentioned, the PRIMARY_BOOT_SRC now is marked as b'1111. This is a reserved configuration, we cannot provide more information about it. There isn't any way to revert these changes and go back to a b'0000 to do an ISP_PIN_BOOT, which is the default state. At this point, I'd recommend getting a new board. 

Regards,

Victor