[Bug 1001443] LPC17XX may be definitely locked if address 0x2FC hasvalid Code Read Protection value

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001443

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-06 13:16:13 GMT ---
(In reply to comment #0)
> See section 32.6 of UM10360: if by lack of luck address 0x2FC holds some
> magical value (defined has CRP1, CRP2 and CRP3, respectively 0x12345678,
> 0x87654321 and 0x43218765) then one may lose access to the MCU.
> 
> CRP1: removes JTAG access + add ISP (UART0 programming) limitations
> CRP2: CRP1 + more ISP limitations
> CRP3: CRP2 + no more ISP unless application makes it available.
> 
> It is very possible that some application has one of these magical values
> exactly at the wrong place and in case of CRP3 the only solution may be to
> replace the MCU.
> 
> In my current setup using only FLASH on a LPC1765, 0x2FC is right in the middle
> of  main().
> 
> I guess the solution is in the linker script (I'm not familiar with it)... one
> should also be able to lock the MCU if wanted but this could be done by
> eventually adding or modifying data in the .hex/.bin file about to be flashed.

A similar issue at Kinetis has been resolved in the linker script + definition
of variable(s) in variant HAL. I guess the method should be applicable to this
case too.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.