RT1064 BEE used in second bootloader

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

RT1064 BEE used in second bootloader

Jump to solution
1,242 Views
martinzhang
Contributor III

Hi,

There is an issue of BEE in my project (MCU is RT1064). The project is a second bootloader which it follows the instruction of AN12064. The bootloader is plaintext and application is encrypted. The situation is:

1> Fuse setting

Set BEE_KEY1_SEL   to  “0b11”

Set SW_GP2 to

SW_GP20:  0x3322'1100

SW_GP21:  0x7766'5544

SW_GP22:  0xbbaa'9988

SW_GP23:  0xffee'ddcc

 

2> Generate the encrypted image by tools “ image_generate.exe “ with command:

image_generate.exe ifile=Test.bin ofile=Test_encrypt.bin base_addr=0x7000D000 region_key=00112233445566778899aabbccddeeff region_arg=1,[0x7000D000,0x28000,0]

 

3> Add jump_to_application  function to bootloader. There is only one small change in function decryption_config

key_sel.option = SW_GP2_FLAG_LE;  //SW_GP2_FLAG_BE is original version

 

My problem is:

In the function jump_to_application, before BEE configuration, it seems the code works well, and the application start and end address got from PRDB is correct. After BEE configured, it seems BEE does not work due to the application entry address and stack pointer are same as the original crypted values.

 

Following screenshot is the register information got after BEE configured.

Any suggestion is appreciated.

 

 

martinzhang_2-1675228492254.png

 

martinzhang_3-1675228509690.png

 

martinzhang_4-1675228521581.png

Best Regards,

Martin

 

 

 

 

1 Solution
1,078 Views
martinzhang
Contributor III

Hi Diego,

Thanks for your reply.

The problem is solved few months ago.

The migrated AN12064 SW can work with RT1064.

The code I updated:

key_sel.option = SW_GP2_FLAG_LE;  //SW_GP2_FLAG_BE is original version

is not correct and I change back.

The reason the encrypted code is not decrypted because I made a mistake of write the expected key in a wrong order.

Fuse has been blown, so I changed the order of key to generate a new image and it works. After the BEE working, in IAR debug mode I can see the encrypted code in the flash changed to the expected.

Best Regards,

Martin

 

View solution in original post

3 Replies
1,206 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @martinzhang  

For the fuses that you burned I recommend to make a readout with our MCUxpresso Secure Provisioning tool  (SPT) . Please share this readout with us, let me know if you need details for how to make this on our tool.

 I would like to clarify your issue a little bit further, please correct me if I am wrong.

 1 You migrated the AN12064.SW to work with RT1064.

 2 After letting the   jump_to_application(...) function  run you discovered that the values of the app SP and entry address are still encrypted. So, basically you can not run  your encrypted  application. 

diego_charles_0-1675976272071.png

3 Eventougth, you where able to see that PRDB is decrypted by DCP (output).

diego_charles_1-1675976420870.png

My apologies for not reaching you sooner. 

All the best,

Diego

 

 

 

 

0 Kudos
Reply
1,079 Views
martinzhang
Contributor III

Hi Diego,

Thanks for your reply.

The problem is solved few months ago.

The migrated AN12064 SW can work with RT1064.

The code I updated:

key_sel.option = SW_GP2_FLAG_LE;  //SW_GP2_FLAG_BE is original version

is not correct and I change back.

The reason the encrypted code is not decrypted because I made a mistake of write the expected key in a wrong order.

Fuse has been blown, so I changed the order of key to generate a new image and it works. After the BEE working, in IAR debug mode I can see the encrypted code in the flash changed to the expected.

Best Regards,

Martin

 

1,056 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi Martin, 

Thanks for your letting us know the outcome.

Diego

0 Kudos
Reply