Updating CFPA page on LPC55 using flash API doesn't always work

[cp1]

I've successfully enabled and tested secure boot for my 1B revision chip.  Now I'm working on updating the CFPA page live so I can update the secureFirmwareVersion field after secure firmware updates.

I'm using the ROM flash API to do the update.  Specifically, I use ffr_get_customer_infield_data to read the CFPA page.  I confirmed that the data read in by `ffr_get_customer_infield_data` is correct, and there is no error code.

I then edit both secureFirmwareVersion and Version fields.  As I understand, if the Version field is incremented in the scratch page, then CFPA will get updated on the next power cycle.  So I increment Version and write back CFPA using ffr_infield_page_write.  I then power cycle and then read back the CFPA page with ffr_get_customer_infield_data.

I've found that when I increment Version by 1, CFPA doesn't update at all (and gives no error code on the write).  If I increment by 2, then it works only once.  It doesn't work again unless I increment by 3, and then only works once.  This continues and seems to indicate that I need to increment Version by a larger amount every time.  For each trial I did a power cycle.  This doesn't seem correct and I cannot find any more documentation on how to use this flash API properly. 

What are the exact steps one should take to use the ROM flash API to update the CFPA page in a repeatable way?  Is there any documentation on the Version field of CFPA?

[Sabina_Bruce]

Hi All, 

Please make sure that you are using the latest version of the SDK possible between when this question was first asked, until now there have been some updates on the ROM API. 

As of now there should be no problem writing to the correct area as well as reading the active ping/pong page. 

VENDOR_USAGE field for LPC55s6x/s2x needs to have the incrementing counter on the upper 16 bits and the inverse on the lower 16 bits. 

I'm attaching an example code that increments some of the values and tries to roll back other values to confirm that these cannot be decremented if they are monotonic.

Import the flashiap example from the latest SDK and replace the main file with the following:

[araratadamian]

Is there any update on this NXP? I'm having the same issue and reading 0x9DE00 doesn't seem to be the correct answer. For example, I'm implementing anti-rollback using IMAGE_KEY_REVOKE, and can increment and decrement the value (on an unsealed device) as much as I want. That said, when I read back the CFPA scratch, ping, and pong pages, they will all tell me my IMAGE_KEY_REVOKE value is 0, but really the ROM is using an older page with a higher IMAGE_KEY_REVOKE that's buffered somewhere else. Then, several (indeterminate) reboots later, that CFPA version will show up in my scratch page.

[Mahesh_Chandra]

Hi,

Can you please add the part number you are using in your project?

[cp1]

After some more experimenting, I found I could avoid these issues by just not using ffr_get_customer_infield_data to read the CFPA page.  Instead, to read the CFPA i just read the 512 byte scratch page by reading from address 0x0009_DE00 directly.  It seems that the ffr_get_customer_infield_data returns old versions of the CFPA that are not in the scratch, ping, or pong pages.