Secure Provisioning Tool v7 fails to start flashloader in RT1064

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Secure Provisioning Tool v7 fails to start flashloader in RT1064

Jump to solution
1,573 Views
jamesli
Contributor IV

 I try to burn eFuse, but SEC fails to open OTP configuration page, here are screen shots, any tips are welcome!

Jian Li

jamesli_0-1713016548276.png

jamesli_1-1713016575843.png

 

 

 

 

0 Kudos
Reply
1 Solution
1,267 Views
jamesli
Contributor IV

Hi, Marek, 

  Many thanks for your help. I tried SEC v8 before and then I repeat to try to start flashloader as you described, it still fails starting. I do not know why you have no problem; I cannot start it. Then I replace the flashloader.srec in v8 with v3.1 two files ivt_flashloader.bin and flashloader.srec; then I perform start flashloader, open OTP configuration and write image into flash, all are successfully as shown below.

jamesli_0-1713905140283.png

jamesli_1-1713905169048.png

jamesli_2-1713905187911.png

   Clearly, v8 is much faster than v3.1 in perform the same tasks. I have not got any new hardware to burn fuse, but I will try that later and believe it should be OK. 

 Thank you for your help again, I am happy this solution and you can close this thread.

 Jian Li

 

 

 

 

 

View solution in original post

0 Kudos
Reply
18 Replies
1,529 Views
liborukropec
NXP Employee
NXP Employee
Hi Jian Li,
is there any reason you are not using the latest Secure Provisioning Tool *v8*?

Regards,
Libor
0 Kudos
Reply
1,525 Views
jamesli
Contributor IV

Hi, Libr,

 Thank you for help, I installed and tried SEC v8 and results are the same? When I try to open OTP configuration in build image tab and start flashloader in write image tab, it fails to start flashloader. 

Jian

 

 

0 Kudos
Reply
1,538 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian Li,

based on your log, the issue is not related to fuses. It seems the flashloader does not start or fails to initialize UART or is not compatible with your board. Are you using EVK board? Have you tried USB?

The flashloader in SEC tool (c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec) is just compiled example from MCUXpresso SDK. You can build your own and debug the problem.

Regards,
Marek
0 Kudos
Reply
1,526 Views
jamesli
Contributor IV

Hi, Marek, 

 

  Thak you for reply. UART is tested OK before and after trial to open OTP configuration as below.

jamesli_0-1713163449705.png

 I can flash my program in UART, why it fails to open OTP configuration? The board is my customized board, there is no USB port. I like to change eFuse for FlexRAM configuration, what is the best tool to do it? Why must I debug and build my own flashloader in SEC tool? Could you please more info on why flashloader not compatible with a board?

Thank you in advance!

Jian

 

0 Kudos
Reply
1,521 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian,

the same flashloader is used in connection dialog to verify the processor. If this succeeded, I do not see any reason why it is failing in OTP dialog.

1) Can you try to increase a delay in preferences, see "Timeout for communication re-established after reset"? Usually it needs more time if the board is connected through some USB hub (so would be good to connect the board directly to your PC).

2) Can you try Generate the script for OTP fuses and in the generated script, can you to duplicate the call:

@echo ### Check presence of FlashLoader ###
call "%blhost%" %blhost_connect% -j -- get-property 1 0

I have seen that sometimes it failed for the first time (the communication is not established) and passed for the second time.

3) Can you also try baudrate 57600?

Regards,
Marek
0 Kudos
Reply
1,484 Views
jamesli
Contributor IV

Hi, Marek,

  Many thanks for your help. I did the following actions as you requested:

1. I increase delay time from 5 seconds to 15 seconds at 115.2k, and 30 seconds at 57.6k baud rate as shown below,

jamesli_0-1713200447001.png 

jamesli_1-1713200510845.png

2. I tried 57600 baud rate as shown above.

3. I try to generate script, but no response from SEC tool, I cannot find the script file in folder of SEC tool. However, I find the script templates as below and it is seems we duplicate "the call: @echo ### Check presence of FlashLoader ### call "%blhost%" %blhost_connect% -j -- get-property 1 0 " by modification of the macro? If so, please advise how to change it.

jamesli_2-1713200710425.png

 In SEC tool manual, " Generate Script is expected to be used on an empty processor. It contains the configuration of all fuses and it might fail if any fuse is already burnt." I thought because I cannot read OTP configuration, there are a few unknown values in some eFuse, that might prevent Generate Script?!

 I will try different hardware tomorrow and let you know outcome.

 Jian 

 

 

 

 

0 Kudos
Reply
1,478 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian,

the "burn" script is no generated if there is no requirement to burn any fuse. All fuses are zero by default and it is possible to burn any bit to 1. If you specify required value as zero, no script is generated, because it is not technically doable to change any fuse to 0.

I still see in the log, the flashloader does not start. Flashloader is a "helper" application running in RT1064 processor allowing to load the custom application and burn the fuses into the processor using "blhost.exe" tool (via UART or USB). It is possible to find the flashloader implementation in MCUXpresso SDK, see https://mcuxpresso.nxp.com, see example project named "flashloader". You can try to run the example project on your board using debugger and check whether it fails or not. If it works, you can replace the default flashloader distributed in SEC tool (c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec) by your own flashloader

In the connection dialog you sent, I do not see any error, so it seems the flashloader was started and connection established. Not sure why the same does not work in OTP configuration dialog. Can you please confirm this? To double-check, can you please start SEC tool with parameter -v (verbose mode, i.e. run securep.exe -v) and go to connection dialog, test the connection and send the log back?

 

Still would be nice to try to generate the burn script and once script is generated, open it and modify

@echo ### Check presence of FlashLoader ###
call "%blhost%" %blhost_connect% -j -- get-property 1 0

to

@echo ### Check presence of FlashLoader ###
call "%blhost%" %blhost_connect% -j -- get-property 1 0
@rem ignore any error and try again
call "%blhost%" %blhost_connect% -j -- get-property 1 0

After this fails, can you run c:\nxp\MCUX_Provi_v8\bin\_internal\tools\spsdk\nxpdevscan.exe. This tool should report, what connections from the processor are available. This might help to understand, whether the flashloader is active or not.

Regards,
Marek
0 Kudos
Reply
1,467 Views
jamesli
Contributor IV

Hi, Marek,

 I start SEC tool with -v, 

jamesli_0-1713217034956.png

Test UART connection is fine as below,

jamesli_1-1713217104164.png

 Then I generate script, in advance mode, burn_user_OTP_cfg_win.bat and modified as you suggested, 

jamesli_3-1713217540180.png

then I try to read OTP configuration, still failed. So that I try to do burn and think it will call the generated script, but it seems not, still call init_flashloader_win.bat as following

jamesli_2-1713217493761.png

I try to scan using nxpdevscan.exe, it fails by try to open wrong port com6, not com7, 

jamesli_4-1713217767007.png

Is this mean flashloader setting is not right?

 Jian Li

 

 

0 Kudos
Reply
1,457 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian,

for the -v option, unfortunately you send a log before the connection dialog, so I do not see whether the flashloader was started or not.

For the fuse burning script, if you modify the script manually, you cannot run the script from GUI, because GUI always generate a new script. Nevertheless, the log shows the COM7 port for flashloader is not available. And nxpdevscan does not show any other available COM port. So, either the flashloader does not start (you can debug, potential HW issue on your board) OR your computer refuses to communicate with flashloader. 

I'd recommend to debug the flashloader.

Regards,
Marek
0 Kudos
Reply
1,297 Views
jamesli
Contributor IV

Hi, Marek,

   I install MCUXpresso v9 and import flashloader example project, there is no instructions in doc folder in the example as normal example project, I do not know how to debug it, and have to read flashloader manual to figure out what to do with the flashloader. What are criteria to judge the example code suitable for SEC tool and acceptable? How to replace it with existed SEC tool flashloader?

   My experience with RT1052 and an external NOR flash memory programming is easy and reliable in my previous project, so I reinstall the older SEC tool, to my surprise, SEC Tool 3.1 can read eFuse as shown below, 

jamesli_0-1713822376014.png

Then I change bit 16:19 in eFuse 0x6D0 to partition FlexRAM, while writing image to flash in the same time, it seems the flash program is OK, write eFuse is failed as following log 

jamesli_1-1713823269782.png

When I reboot, the flash memory boot to run in RAM is OK. When I try to open OTP configuration, eFuse 0x6D0 has changed even log report failed. Before fuse burn, 0x6D0 was 0x00000040, now it is 0x00020040, am I right?

jamesli_2-1713823315984.png

 Now, I am confident that there is no hardware problem with my DSP PCA, old version 3.1 is better than newer versions v7 and v8, can I use flashloader in v3.1 to newer version? If yes, please advise how to do it?

  Jian Li

 

 

0 Kudos
Reply
1,274 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian Li,

I'm happy that you find the workaround.

the flashloader in SEC v8 is located in "c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec"

in SEC v3.1, thew flashloader is provided in two formats:

1) "c:\nxp\MCUX_Provi_v3.1\bin\data\targets\MIMXRT1064\flashloader.srec"

2) "c:\nxp\MCUX_Provi_v3.1\bin\data\targets\MIMXRT1064\ivt_flashloader.bin"

I tried with RT1064-EVK to use flashloader marked as 1) in SEC v8 and I did not find any problem. I also did not reproduce your issue in SEC v8 with original flashloader. I tested UART with 115200 baudrate.

Can you please test SEC v8, using "Start flashloader" button on the Write tab? Just select UART on the toolbar, reset the processor and then hit "Start flashloader" button. Kindly test first with the original flashloader and then with flashloader from SEC v3.1 and please let us know your result. Below I'm sending the screenshot, how it looks on my computer

marektrmac_1-1713870119405.png

marektrmac_2-1713870233767.png

 

 

Regards,
Marek
1,268 Views
jamesli
Contributor IV

Hi, Marek, 

  Many thanks for your help. I tried SEC v8 before and then I repeat to try to start flashloader as you described, it still fails starting. I do not know why you have no problem; I cannot start it. Then I replace the flashloader.srec in v8 with v3.1 two files ivt_flashloader.bin and flashloader.srec; then I perform start flashloader, open OTP configuration and write image into flash, all are successfully as shown below.

jamesli_0-1713905140283.png

jamesli_1-1713905169048.png

jamesli_2-1713905187911.png

   Clearly, v8 is much faster than v3.1 in perform the same tasks. I have not got any new hardware to burn fuse, but I will try that later and believe it should be OK. 

 Thank you for your help again, I am happy this solution and you can close this thread.

 Jian Li

 

 

 

 

 

0 Kudos
Reply
1,234 Views
marek-trmac
NXP Employee
NXP Employee

Jian Li,

We are happy you can now use SEC tool v8. Still, it would be nice to understand, where the flashloader problem is so we can fix it properly. Can you please also try attached flashloaders?

- evkmimxrt1064_flashloader_v_2_11.s19 - comes from MCUXpresso SDK 2.11 and it should be same as distributed in SEC v8, just built using MCUXpresso IDE 11.9.0

- evkmimxrt1064_flashloader_v_2_15.s19 - comes from MCUXpresso SDK 2.15 (latest), built with same MCUXpresso IDE. 

Both flashloaders works on our side.

 

Regards,
Marek
0 Kudos
Reply
1,193 Views
jamesli
Contributor IV
Hi, Marek,
I have tried these two versions flashloader, both are failed by reporting "Selected UART device not found" after 30 seconds waiting in my PC. I compile the example flashloader from SDK2.15 without change, it also fails and even worse. Sorry for bad news. Jian
1,182 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian,

thank you for you verification. Could you run the flashloader in debugger in MCU IDE 11.9 and send the screenshot where it fails? What is the last function/command executed and what command failed and what's the exception?

In MCU IDE 11.9, there is no needed any specific setup. Just open the "flashloader" example, build and debug.

We suppose the flashloader might initialize some peripheral, and this peripheral does not work on your custom board and this causes the failure.

Regards,
Marek
0 Kudos
Reply
1,174 Views
jamesli
Contributor IV

Hi, Marek,

 Here are screen shots when I debug it,

jamesli_1-1714058919345.png  

 

jamesli_0-1714058891368.png

 

Jian

 

0 Kudos
Reply
646 Views
marek-trmac
NXP Employee
NXP Employee

Hi Jian,

thank you for the additional details about the problem. From your screenshot I understand the flashloader failed on address 0x20010A7C. On this address, there is function for clock initialization - configure_clock(). I suspect the failure might be caused by different clock source, Xtal frequency, or some other problem related to clock configuration.

We tried to compare the source code of the flashloader with previous version, but we did not find any difference (the clock initialization is quite complex, so we cannot guarantee that there is no difference).

We did not identify any problem in the flashloader itself, so we will not change flashloader in the SEC tool. You still can use your own version of the flashloader in next versions of the SEC tool.

If you find any additional details about the problem, please let us know.

Thank you very much for your cooperation to investigate the problem.

Regards,
Marek
0 Kudos
Reply
640 Views
jamesli
Contributor IV

Hi, Marek,

  Many thanks for your help and explanations.

The additional details are, my PC is Lenovo Think pad with window 10 enterprise version 2H22, at least 4 my colleagues (use Lenovo, Think Pad, may be different serial numbers, but the same window 10 version) have the same problems when using SEC v7 or v8, when try to flash program a new build of PCA first time (new DSP MCU IC from factory), it works fine. After the first time, flash program the same DSP PCA is always failed due to flash loader failed to start. Sometimes, I have to erase the MCU flash memory with MCUXpresso plus JLINK probe first, make it like a new MCU, that may work sometimes, (by re-starting PC, restart SEC Tool, etc), but not always lucky. Read eFUSE CONFIG always failed.

  Now, I am using SEC v8 with SEC v3.1 flash loader replaced SEC v8 its own flash loader as we discussed a few weeks ago. That works much better than SEC v7 or SEC v8 with its own flash loader. Now I can read eFUSE CONFIG and flash program without problem, only when burn eFUSE, it reports failure, but when re-load eFUSE CONFIG again, the eFUSE has been changed as required. Hopefully, it is really changed because the flashed program re-boot and starting correctly after power recycle. 

Regards!

Jian Li

0 Kudos
Reply