How could I use the MCUBootUtility with a custom board with only the JLINK connection

[VolcanicCheese]

I have custom board designed based on RT 1020 Eval Kit, but the current custom board has only JLINK for connecting to the board. I was wondering how I could use the MCUBootUtility to burn the eFUSE to change bootmode with the JLINK connection, I also got a MCU LINK debug probe hoping that would fix my issue, but I was not able to find any guide on how the connection should work with the 1020 Dev Board. Thank you!

[Noah69]

It does not seem like I could use the MCU Boot Utility. I tried with the JLINK commander to write a bit to address based on the reference manual to burn the fuse, but I am not sure what I did wrong.

[kerryzhou]

Hi @Noah69 ,

  Yes, of course, you can use the code to burn the fuse.

   But at first, we still need to check the customer boot mode situation.

  About burn fuse with the code, customer can refer to code:

SDK_2_11_0_EVK-MIMXRT1020\boards\evkmimxrt1020\driver_examples\ocotp

More details about the fuse map, check RM  Chapter 23 On-Chip OTP Controller (OCOTP_CTRL) and  Chapter 22 Fusemap

Best Regards,

Kerry

[kerryzhou]

Hi @VolcanicCheese ,

    MIMXRT1020 can use the JLINK connect the chip with SWD interface directly, you don't need to modify the fuse. If you leave the SWD interface, just use your debugger to connect it.

   As it is your own customer board, at first, you can use the JLINK command to connect the RT chip at first, whether it can find the ARM core or not, when you can find the ARM core, the hardware is OK to connect, if you can't find the ARM core, it means your hardware still have issues.

   This is the JLINK command connect result with JLINK and SWD interface to RT1020:

Please note, normal use, don't modify the fuse.

Best Regards,

Kerry

[VolcanicCheese]

Our custom board does not have a switch 8. Because there are no switches, the custom board boots up in serial downloader mode. I learned working with another NXP engineer that I need to burn the eFuse to make the MCU boot in internal boot mode. This is the link: https://community.nxp.com/t5/i-MX-RT/Trouble-flashing-custom-board-designed-based-on-the-1020-Eval/m...

After the link, I have been trying different tools seen based on what I have seen in different forums. It does not seem like I could use the MCU Boot Utility. I tried with the JLINK commander to write a bit to address based on the reference manual to burn the fuse, but I am not sure what I did wrong. When I read from the address, it did not burn the fuse properly. After that, I tried to figure out how to use it with the MFG tool. I am not sure but it seems like I need to write a script to make the tool work. I was not able to find any documentation on where and how to write the script to burn the fuse.

[kerryzhou]

Hi @VolcanicCheese ,

   Thanks for your information.

   If you want to use the MCUBootutility, you need:

1. chip enters the serial download mode, BOOT_MODE[1:0]=0:1

2. BOOT_CFG pin needs to use the related flash configuration.

So, please help to check your hardware, do you leave your BOOT_MODE[0,1] pin, and BOOT_CFG pin?  And the UART interface or the USB interface

If you do not leave, you can't select the boot mode with the pin.

Please help to confirm your schematic at first.

Best Regards,

KERRY

[VolcanicCheese]

Our custom board boots from boot from fuses mode. By default, the MCU starts up with serial downloader when there are no fuses programmed. We need to burn the fuse to start the MCU with internal boot mode so that we could boot it up with the external flash. The Boot_CFG pin is the same as the default configuration on the dev board. I tried both USB and uart to see what works. I was not able to connect with it with the dev board with the SW8 configured to be boot from fuses mode. I was wondering how could we burn the fuses by using a JLINK connector? I would like if you could show me step by step guide on how I could burn the fuses to set it up to internal boot mode using a JLINK connector? Thank you!

[VolcanicCheese]

Also, I had no trouble connecting the dev board and custom board using the JLINK commander. For now, it does not seem like an issue with the custom board when I get the same results with the dev board. Thanks!

[kerryzhou]

Hi @VolcanicCheese ,

  So now, all your issue is solved, right?

  If your question is solved, please help to mark the correct answer, just to close this case, thanks.

Any new issues, welcome to create the new case.

Best Regards,

Kerry

[VolcanicCheese]

No, I was just trying to provide extra context. I still need help with burning the eFuse using the Jlink commander.

[kerryzhou]

Hi @VolcanicCheese ,

  You can use the SDK code:

SDK_2_11_0_EVK-MIMXRT1020\boards\evkmimxrt1020\driver_examples\ocotp

 to burn the fuse.

  About the detail fuse bit information, please check the RM OCOTP chapter and the fuse map.

Best Regards,

Kerry

[VolcanicCheese]

Thank you for taking the time and answering my question.

Context of the Question

I am currently using a Jlink EDU connector.

The board is in serial downloader mode. 

I tried flashing and debugging the board with the SDK project. 

I set up the fuse map address and write the value as shown below for the example project to burn the eFuse to set up the boot mode to internal boot mode.

I figured out the fuse map address and fuse write value based on this page on the reference manual.

Flashing the program do not do anything because it seems the project works on runtime.

Question: Where do I setup the fuse map address and write value to burn the fuse with serial downloader mode using a Jlink Connector with the OCOTP example SDK project?

[kerryzhou]

Hi @VolcanicCheese ,

   You need to download the code to the internal RAM in the serial download mode, can you debug it step by step?

   If yes, then you can follow the fusemap and the OCOTP register do the read, write, and read, whether that works on your side?

   Your mentioned your fuse didn't work previously, please tell me which detail area you modified? And the readout value, then I will help you to check the position.

   If you can debug step by step, you even can check the register directly.

   Now, what's the IDE you are using?

Best Regards,

Kerry

[VolcanicCheese]

Thank you for taking the time to read my question and answering them!

Question: You need to download the code to the internal RAM in the serial download mode, can you debug it step by step?

Answer: No, I was not able to debug it step by step and I was not sure how to ensure that the code gets download to the internal RAM. When I run the code,  It gets stuck at the boot ROM as mentioned on the post that I linked.

Question: Your mentioned your fuse didn't work previously, please tell me which detail area you modified? And the readout value, then I will help you to check the position.

Answer: Sorry if this does not make any sense, what I am saying. I am new to this and trying to figure this out. I am using the Boot Mode Register Address and trying to write a bit to BT_FUSE_SEL.

I was not sure where in the example SDK project I am supposed to write the fuse map address and write value. Looking at the example SDK project. It seems like I need to write the values here as shown in the screenshot below:

But is this not for the shadow register? I thought the shadow register works by allowing you to see what happens if you do burn the eFuse without burning the eFuse.

Question: Now, what's the IDE you are using?

Answer: MCUXPRESSO IDE

[kerryzhou · Accepted solution]

Hi @VolcanicCheese 

1. Run code in RAM in the MCUXPresso IDE

Answer: Please use the following configuration:

Select the Link application to RAM, then your code will run in debug mode, even you work in serial download mode, I have tested it, and confirm serial download mode, the RAM debug is OK.

2. I was not sure where in the example SDK project I am supposed to write the fuse map address and write value

Answer: You are right, EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE is used to control the write code, as you know, fuse is one time operation, it just can be modify from 0 to 1, and can't write back. So, to the SDK code, it is very careful, and don't want the customer write the fuse directly, so it just give a fuse read version.

When customer need to write the fuse, customer can set 

#define EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE 1U.

You also need to double check the fuse address, which is the correct address area.

To be honesty, to the new user, normally, I don't recommend customer operate the fuse, but your customer board situation is special, you didn't leave the GPIO for the BOOT_CFG.

Wish it helps you!

Best Regards,

Kerry