1064 BEE using trouble

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

1064 BEE using trouble

1,308 Views
KKVaka
Contributor I

Hello.

I have some trouble with BEE crypting. The code consists of two parts - bootloader and user application. Fuses are set to enable crypt with key at SW-GP2. Without sections with protected region description code works ( both parts ), even with IAR-debug. 

When I make common binary ( 2 bin parts, one by one ) and write it to flash witout crypting - it works well. But if I use MCUXpresso Secure Provisioning v3.1 and crypt it ( 2 separate protected areas for my bootloader and application ) - works well only bootloader. It can see application-part well ( searching of version string texts inside code is successfull ), and try to run application.

User-part of initialisation ( SystemInit ) works well ( led is turning on at the end of procedure ), but execution is stopped before "main" function ( led does'nt turning off ). With IAR-debug I can walk trough "__iar_program_start" code, but in crypted mode it dos'nt work. And I can't change that library-code to locate a trouble.

The encryption settings are as follows

Engine Selection: Engine 0
Engine key Selection: Random Key
Key Source: Fuse SW-GP2
AES Mode: CTR
Protected Region Count: 2
Protected Region Start 0: 0x70002000
Protected Region Lenght 0: 0xE000 
Protected Region Start 1: 0x70012000
Protected Region Lenght 1: 0xEE000

What can I try to do with this trouble?

Labels (1)
0 Kudos
Reply
3 Replies

1,270 Views
KKVaka
Contributor I

I found a way to make the program work. It is enough to enable code size optimization and at the same time libraries are used that do not use problem processor instructions. It's a way to run a program, but the CPU still can't execute those commands properly (from what I can see).

0 Kudos
Reply

1,278 Views
KKVaka
Contributor I

Unfortunately the problem remains. I was able to find that running LDM or LDMCS commands in the __aeabi_memcpy4 subroutine with BEE enabled causes a HARDFUAULT exception. The result is not stable and occurs here and there (apparently it depends on the address where the command is located). Command and data caches are disabled and should not affect the situation. The read addresses are aligned, this cannot be the cause of the exception. Encryption and recording is performed by the MCUXpresso Secure Provisioning v3.1 program ( I use BEE-CRT crypting with SW-GP2-Key = 0 ), after recording the code is decrypted correctly (I checked and compared), so there is no doubt about the accuracy of the decrypted code. The same code without encryption works fine.

I suspect that there is a hardware kernel error here, which is not clear how to compensate.

 

0 Kudos
Reply

1,291 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you refer to the application note to implement the second bootloader solution and the download link of its associated demo code is attached below.

https://www.nxp.com/docs/en/application-note-software/AN12604SW.zip

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply