How to protect Flash from ISP routines (LPC2103)?

[mjbcswitzerland]

Hi

I have a product using an LPC2103 which has been in production since about 2010 and there are an increasing number of returns (old and new equipment) since they stop working. In each case it is found that a single (or maybe more) sector of flash has been deleted (often the first sector 0x0000..0x07ff but also others can lose their program - eg. 0x6800..0x6fff).

The application does include a parameter system that can erase flash but it only erases a single sector (last one) when it becomes full. The API routines that are used also check the sector that is commanded and will reject anything other than this last sector's number. Since the last sector is only party filled when such code loss take place there is no reason to suspect that an intentional erase is going wring.

The application stores its present state in battery backed up RTC registers so after power loss an active program can be continued (that is, the products operation can continue after a power failure half way through). When the code is reprogrammed (to recover the operation) it is usually the case that the program continues from where it was in active operation, rather than from an idle state. In active operation is switches some actuators that could potentially cause some interference and it is assumed that such interference is the root cause of the problem.

If interference causes a reset (watchdog) is is not serious since the program continues from where it was but the fact that program code is lost is of course a more major concern.

Since all points to ISP being started randomly due to some interference and deleting a random sector of code I would be interest in finding a method to block ISP from being able to delete any of the code sectors.

Chips show :

Device ID 4FF11 Bootloaderversion 2.21

Are any such cases of this behavior known and what could be done to protect the program code??

Best regards

Mark

[CarlosCasillas]

Hi Mark,

I have internally asked if there are some information regarding the described behavior.

I will post an update as soon as having news.

Best regards!

/Carlos

[mjbcswitzerland]

Thank you Carlos

Note that I have used also LPC2106 in large quantities in the past (from about 2004) whereby it was necessary to update the ROM loader (in early parts). To do this I developed a utility for production use which would check the loader version and perform an update.  In case it were possible to somehow update the ROM loader (which includes the ISP code) to include some form of additional protection (if needed) I suppose it could be used for the LP2103 part too....(?)

Regards

Mark

[CarlosCasillas]

Hi Mark,

Below you can find internal reply:

A recommendation is enabling CRP and protect MCU from ISP mode, as explained on page 246 of User Manual UM10161:

https://www.nxp.com/docs/en/user-guide/UM10161.pdf

CRP3 can disable ISP function after hardware reset. special noticed here, customer better open a backdoor in application code the reason is:

Once enabled CRP3, the JTAG and ISP functions are all disabled. User can not debug or update firmware through JTAG or ISP.

Believe the ISP firmware won't erase other sectors. So, other recomendation is checking the IAP or firware update function.

Make sure hte IAP is running on SRAM area and disabled interrupt before operate flash by IAP

Hope this will be useful for you.

Best regards!

/Carlos

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

[mjbcswitzerland]

Hi Carlos

I have taken a look at this possibility but don't think that I can use it.

The problem is that I still need to be able to write to and erase the final sector of the Flash to store parameters (that the user can update at any time). If I use CRP2 to disable erasure of single sectors and writing to flash then this function is lost.

The only possibility that I see at the moment is to modify the ISP functions themselves to only allow a mass erase (which has never occurred sporadically in the filed) or an erase of just the final sector:
- note that I have analysed a number of failed devices and the last flash sector has never been deleted - often 0x0000..0x0fff is blank but in some cases 0x3000..0x3fff and I also saw 0x1000..0x4fff blank once.

- in three cases I found that there we no deleted sectors but the processor would not run until re-programmed; I have made backups of the flash content and will try to find whether maybe a line of code has been sporadically modified, which may also need programming to be restricted to the final sector in normal circumstances (eg. when chip is not erased).

Since the firmware is otherwise stable - no updates for a number of years - I may be willing to sacrifice firmware updates in the field in favor of devices not failing. The question is whether it will be possible to reverse engineer the ISP functions in the boot ROM and reprogram them???? As mentioned previously I have updated the boot ROM in early LPC2106 parts so I assume that there is an update mechanism in the LPC2103 too (?) - it is not a task that I look forward to but the failures in the field are becoming a major concern.

Regards

Mark

[CarlosCasillas]

Hi Mark,

An additional reply from AE team include the following:

It can used the CRP command to disable ISP and JTAG functions to flash.

And using IAP command to write to and erase the final sector of the Flash to store parameters. Because IAP commands are not affected by the code read protection. Take a look to UM page 246:

So, the option could be trying the CRP on one bad devices.

Hope this will be useful for you.
Best regards!
/Carlos

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

[mjbcswitzerland]

Hi Carlos

Many thanks for the update.

This means that the rules for "internal" and "external" ISP commands are different.

I will verify first that the application works normally in CRP2.

Since I am worried that the problem is sporadic 'internal' ISP it may not help protecting the operation but in case it proves to be external ISP (eg. a disturbance causes the board to reset, enter ISP mode and interpret a command) it may do so.... !

The down side is that it will no longer be possible to analyse what part of memory was lost since the read will not be allowed, but if it results in an improvement this wouldn't be necessary anyway.

Regards

Mark