LPC5512 (non-S) debug/read-out protection?

[Gorvak]

I'm struggling to find the available options for debug protection on this IC due to most of the documentation talking about debug authentication on the 'S' version of the IC.I've really got no interest in using certificates and signed code.

Does the non-S version of the IC support any kind of debug protection?

Ideally, I want to be able to ensure that the flash contents cannot be read out (read-out protection) for production, but if a mass erase is carried out then the chip reverts to normal and allows programming and debugging until such time as the read-out protection is enabled again.

Is this possible?

[ZhangJennie]

HI Gorvak

LPC5500 non-s part doesn't support secure boot and debug authentication. BUT, luckly, we still can configurate debug auth related PFR region to configurate the debug access, debug access will be configurated based on related PFR region and cannot be changed(because it doesn't support debug authentication).

Have a nice day,

Jun Zhang

[Gorvak]

Hi,

Our idea is to have SBL supporting USB so ISP/SWD not needed or desired in the field, but if problem in SBL, we'd prefer not to throw away 10,000 ICs to reprogram the SBL, so if application could be uploaded via SBL to re-enable access that would mean we could then update SBL.

It appears from the documentation that as long as we don't write the hash to the PFR, the PFR is always updateable from an application even if SWD and ISP are turned off ? So the part is never "sealed". Is this correct?

[ZhangJennie · Accepted solution]

Hi Gorvak.

LPC5512 follows customer development lifecycle state, see UM11295 10.3 LPC55S1x/LPC551x Customer Development Lifecycle state.

For LPC551x, When user writes PFR to move state from Tier1 -> Tier2 -> OEM closed, It can’t reverse back. That’s to say, if user has debug port disabled by config lifecycle state, no way to reopen it. But user can still use own SBL to update firmware.

Please be careful when write PFR.

Have a nice day,

Jun Zhang