LPC1768 trouble

Note that at reset, there are no PLL settings. The PLL will be activated a while later, after the primary boot loader have checked any CRP settings, the signature of the interrupt vector table and the state of P2.10.

If CRP allows it, and P2.10 requests it, then the primary boot loader will wait for FlashMagic programming, and PLL settings will not matter.

Note that it can be quite easy to manage to create settings that violate the PLL limitations, which is why such changes should be done with CRP disabled and preferably with a pause from boot until PLL activation. If you for some reason have a corruption in the generated binary, then a lot of interesting things can happen. Not only can you get wrong PLL settings. You can also get the processor to enter power-down state where it may shut down the flash and may stop the oscillator.

Have you checked the map files to see what memory regions your corrupt program tries to program? Does it reach outside of existing flash memory? Does it contain data at address 0x2FC and the following 3 bytes?

If you can prove that the binary does not overwrite the CRP address and does not program outside of existing flash, then it really should be safe to program even a corrupt binary, since reset+P2.10 should be enough to catch the processor and erase/reprogram. It would be very interesting to know what address range it tries to program when you say you lose it after about 70% of the download.

Note that at reset, there are no PLL settings. The PLL will be activated a while later, after the primary boot loader have checked any CRP settings, the signature of the interrupt vector table and the state of P2.10.

If CRP allows it, and P2.10 requests it, then the primary boot loader will wait for FlashMagic programming, and PLL settings will not matter.

Note that it can be quite easy to manage to create settings that violate the PLL limitations, which is why such changes should be done with CRP disabled and preferably with a pause from boot until PLL activation. If you for some reason have a corruption in the generated binary, then a lot of interesting things can happen. Not only can you get wrong PLL settings. You can also get the processor to enter power-down state where it may shut down the flash and may stop the oscillator.

Have you checked the map files to see what memory regions your corrupt program tries to program? Does it reach outside of existing flash memory? Does it contain data at address 0x2FC and the following 3 bytes?

If you can prove that the binary does not overwrite the CRP address and does not program outside of existing flash, then it really should be safe to program even a corrupt binary, since reset+P2.10 should be enough to catch the processor and erase/reprogram. It would be very interesting to know what address range it tries to program when you say you lose it after about 70% of the download.

I looked on new and previous startup file and find edited CRP code in previous one.

;IF :LNOT::DEF:NO_CRP
;AREA |.ARM.__at_0x02FC|, CODE, READONLY
;CRP_Key DCD 0xFFFFFFFF
;ENDIF

Don’t ask me why the code was edited with semicolon, I’m not the only developer in our company. Can be edited CRP protection the reason of this problem?
But still, this startup code is working with other projects.