This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Please do not reply to this email. Use the web interface provided at:

Ilija Kocho <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #1 from Ilija Kocho <> 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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]