CLI based tool to handle OTP, eFuse to help with board bring-up

[mimlo]

Hello,
I'd like to know if there is a possibility to handle the read/write functionalities of eFuses on IMXRT1176 microcontroller.
In my case, I have a custom board that requires me to verify the state of fuse bits and if it's needed to set them to a proper state.
I need to configure boot pins for my every board with my uC, which will have set it to internal boot mode.

Having to do so manually (via seria bootloader using UART/USB) is a total waste of time when a considerable numbers of boards is considered.

There are 2 solutions that I see here:
- run this via dedicated CLI based tool that can communicate via some interface like UART/USB (or over a debug probe?), execute commands and then flash the image and run the code.
- Run the code from RAM, set proper eFuses if necessary and then boot from FLASH. It could be automated via some debug probe like Jlink or mcu-Link to run 2 consequent images, One from RAM that will set the fuses, disconnect and then load the code to FLASH where the application can start from after setting the eFuses to correct boot mode in previous RAM based application.

Are there any useful other alternatives? 

[diego_charles]

Hi @mimlo 

I am sorry for the delayed response!

I do not see, at this moment, other way to write and read fuses than the two ones you are describing. What is the best alternative for you? Are you willing to use SWD or UART/USB instead? Asking this to determine the best way to help you. 

For example you could run an script to read fuses using MCU-Link.  For example adding this to the scp. We have tested this for the RT1020 .scp

450 REM ====== READ UUID ======
460 r% = Peek32 this 0x401F4410
470 PRINT "UUID0 : "; ~r%
480 r% = Peek32 this 0x401F4420
490 PRINT "UUID1 : "; ~r%
500 REM ========================

You could use our MCUxpresso Secure Provisioning tool ( SPT) to read manually and program fuses. This involves using UART/USB alternative.  The tool also lets you to use an automated way for production with is called manufacturing tool. 

Of course you could create your own scripts for your method and use low level SPSDK APIs, which are invoked by the SPT tool CLI. 

If I can help you further please let me know. What makes this reply to be general is that I do not know the fuses you want to check and write. Maybe there could be a better alternative for you or a different path. For example, if you enable HAB or secure JTAG.  If you think this information is way to sensitive, we could create an support ticket and discuss there. 

Diego

[mimlo]

Hi @diego_charles,
The idea with custom SCP script seems like a way to go for me, at least for now. I will probably investigate other methods (like the provisioning tool you mentioned) as well to just see how it can handle things.

Since I will be using jlink in a matter of weeks (replacing nxp debug probe), I guess the same thing can be done there but using .jlink files, which are equivalent in terms of purpose (but may differ in terms of offered functionality).

Could you be so kind and point me to some SCP script file documentation/manual?
I failed to find any documentation on that topic. I guess it should exists somewhere right?

[diego_charles]

Hi @mimlo 

Thank you very much for your reply and interest. 

Currently, we do not have such documentation, but I am checking internally about an example for read and write  using our Linkserver. So I want to get back to you, if we do not have anything I will let you know. 

Btw, our MCU-Link Pro supports  Segger's  J-link  and NXP's linkserver. It just comes from factory with our Linkserver FW installed but you could manually update to Segger's J-link with some simple steps. Maybe getting this as well this debug probe could be handy for your developing experience of testing concepts. 

Additionally, please feel free to explore the SPT GUI, you can create another detailed post if you have questions or comments for the SPT. 

I hope this could help you. 

Diego

[mimlo]

Hi @diego_charles ,
In terms of NXP debug probes, I'm currently using NXP MCU-Link debug probe. I do not have an access to to other debug probes from NXP right now.
Since we already had some Jlinks around, I thought about using them as they seem to be more feature rich (even though the MCU-Link does the job well). It's just there may come a time when we will need some features from Jlink and if we were already accustomed to using it, the whole experience would be much more pleasant and smoother.

For the redundancy reasons, we will probably keep support for both for better safe than sorry reasons as well as due to the fact that MCU-Link probes are much cheaper than jlink ones.

Please keep me posted about your finding. Maybe it'd be worth to add this document to knowledge database on the forum or via some blogpost? - Just an idea.

Best regards,
Michael

[diego_charles · Accepted solution]

Hi @mimlo 

Thank you for your reply! 

I have more details about the Linkserver and .scp script option I mentioned earlier. The .scp files are used by linkserver. If you debug/program a project using the MCUXpresso IDE and an NXP debug probe, running CMSIS DAP. You will see the execution of a connect script .scp. Below an example. 

This sample log on the terminal comes from Using the GUI Flash Tool, embeded on the IDE with a customized .scp file. This time using i.MX RT1020

On simple terms, this customized .scp allows you to use a NXP debug probe to read registers of the MCU and print their value on the terminal.

The customization came from adding extra code lines to the default, RT1020 scp file to read UUID value, Boot_CFGx registers and another register, the SRC_SBMR2, which reflects the value of the boot mode pins. 

The UUID and Boot_CFGx registes are not actual OTP fuses, they are shadow registers, that can be easily accessed. So far Linkserver, or NXP debug probes does not provide a way to burn fuses for the i.MX RT. As seen in this example, you could read shadow registers easily. 

If you want to program fuses easily, over SWD using Segger-s J-Link, you can use .jlinkscript or flashloader to implement fuse programming. Additionally and derived from that  you could explore on your own, other options. Our FAE colleague Calvin Ji had  created one J-Link flashloader with fuse programming feature https://github.com/jicheng0622/All-in-One-Flash-Algorithm-for-NXP-i.MXRT

I hope this could help you!

Diego

[mimlo]

Hi @diego_charles,
Thank you very much for the link to the flash programmer github link. We have our flash programmer design and it's a great idea to incorporate setting the eFUSEs in the flash loader application code since it's loaded into RAM memory every time the debugger tries to upload the image into the flash memory of the uC. That would definitely take care of things for us and there would be no need to come up with anything custom made besides the flash loader itself, but we already have that.

Reading shadow registers is also a great idea, thanks for that as well.

Last question to you:
I assume I can read any memory mapped address of the microcontroller that is available for reading and display that or there are some exceptions to this?

Thanks again!

[diego_charles]

Hi @mimlo 

I am glad that the information worked for you!

That is a good question, I have not tested so far, as this is trick that can be used for customization,  but I presume that there will be some exeptions, generally speaking there  are several registers, memory map areas, that I think would need to be initialized before reading them, using a routine. 

Diego