SC573 security problem

We connect our device through UART (FTDI chip onboard) and Ethernet. We do not use JTAG. There is no standart driver for cldp for that case.

We use only OTP API functions (adi_rom_otp_get, adi_rom_otp_pgm, adi_rom_otp_lock).

The same code on Blackfin BF707 lock the device.

After C code:

uint32_t otp_GP1[ROM_OTP_SZ_gp1]; adi_rom_otp_get_data(otp_GP1, 0x48C, 1);

otp_GP1[0] equal 1.

Before lock we successfull write: otpcmd_secure_emu_key, otpcmd_pvt_128key0, otpcmd_public_key0.

How can it be, that device after successfull request 'adi_rom_otp_lock' remain unlocked?

Maybe we must write to otp more information?

Hi,

Have you ever found a solution for your problem?

I have exactly the same issue like you, see:

https://ez.analog.com/dsp/sharc-processors/f/q-a/121875/sc573---problem-with-securely-locking-device

Any suggestion would be appreciated.

Gerhard

Hi,

Have you ever found a solution for your problem?

I have exactly the same issue like you, see:

https://ez.analog.com/dsp/sharc-processors/f/q-a/121875/sc573---problem-with-securely-locking-device

Any suggestion would be appreciated.

Gerhard

Unfortunately we didn't find solution yet.

ADI didn't want to acknowledge this problem. Maybe they didn't have workaround?

Hi,

Have you tried with Open part before locking the part? Before programming into OTP, we would suggest you to setup secure booting on an open, non-locked part for development and testing.
The ROM code provides a mechanism to boot a secure boot stream on an open part without writing any keys into the OTP memory. This can be very useful in validating the generated key and
application stream before writing to OTP memory. Please follow the application note EE-366 for more details about Understanding the SecureBoot_OpenPart Example Project.
www.analog.com/.../EE366v02.pdf

Please ensure that you have the Secure registers configured in your application. The peripherals which are used in your application only needs to be configured for the secure privileges on the SPU_SECUREP(n) registers. Also, we would also suggest you to check the system cache configurations.
You can refer SPU chapter of the Hardware Reference Manual and ezone thread for the reference. The link for the same is given below.
www.analog.com/.../adsp-sc57x-2157x_hwr.pdf
ez.analog.com/.../117133

Regards,
Anand Selvaraj.

Hi, 

If the ADSP-SC57x family of processor is not getting locked even after programming the security lock bit, this could be due to the fact that security lock bit feature is not enabled on these devices.

This can be resolved using a patch which will enable you to program the component via JTAG connection.

Please contact processor.support@analog.com to get this patch.

Thanks,

Harshit