LPC MicrocontrollersのトピックLPC55S69 - unsealed CMPA erase

LPC55S69 - unsealed CMPA erase

bricker — Fri, 27 Nov 2020 10:26:10 GMT

Is there any way to erase the CMPA region if it is not locked/sealed, i.e. if doesn't contain the digest at its end?

If not, is there a way to flip the secure boot field (SECURE_BOOT_CFG.SEC_BOOT_EN) back to 0b00 (plain image)? I saw another post where the answer was that, once enabled, secure boot cannot be disabled anymore, but the context was not clear there (how the enabling process was performed, i.e. was the CMPA digest written or remained all zeros).

Re: LPC55S69 - unsealed CMPA erase

FelipeGarcia — Tue, 01 Dec 2020 22:49:36 GMT

Hi,

You can change the configuration as long as CMPA is not sealed (HASH of CMPA written). Also please check below extract from AN12283 that confirms this.

This page could be locked after manufacturer programs the page. This is done by writing the SHA 256 digest of the CMPA page into the SHA memory space of CMPA area.

Regards,

Felipe

-------------------------------------------------------------------------------

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.

------------------------------------------------------------------------------

Re: LPC55S69 - unsealed CMPA erase

bricker — Wed, 02 Dec 2020 08:56:27 GMT

Hi,

Thank you for the response.

I've noticed in my experiments that, if CMPA is not sealed, I can change (set to zero) any field in it using the ISP API (e.g. blhost write-memory) except for ROTKH.

On the other hand, using the IAP API (FFR_CustFactoryPageWrite), I can set the entire CMPA page to zero, including the ROTKH part.

Please confirm that this is the expected behavior of these APIs.

Also, as it seems that an unsealed CMPA page cannot be erased directly with ISP API, would the erase command work from within an SB2.1 image. In other words, would ROM code agree to perform this kind of sequence from a cmd_file.bd:

options
{
flags = 0x8; // SB2.1, encrypted + signed
buildNumber = 0x1;
productVersion = "1.00.00";
componentVersion = "1.00.00";
secureBinaryVersion = "2.1";
}

sources
{
inputFile = extern(0);
}

section (0)
{
erase 0x0..0x40000;
load inputFile > 0x0;
erase 0x9e400..0x9e5ff;
}

Regards,