LPC1768 trouble

Not sure what goes wrong that makes the processor hang, but maybe you are trying to download to a memory region that doesn't contain any flash memory. You should take a closer look at the map file for the project.

Another thing to be careful about is that you can lock out the internal boot loader and/or the JTAG interface if you happen to activate the code-protect feature.

But can be primary bootloader or reset function overwritten? I have suspected CRP protection mode at beginning, but most suspicious is that the reset doesn’t response anymore. The output pins are at 3.3V in high state, but when you reset the uC, the output drops to 2.4V and stay at 2.4V when the reset button stays pushed in normal operation. In my situation the output pins stay at 3.3V by pressed reset button.

It's a bit strange that you get 2.4V. I would have expected all processor pins to be held at 3.3V while the reset is active - unless there is external components drawing the signal low.

The reset condition should be all GPIO as inputs with a weak pull-up activated.

2.4V is more common for a GPIO that is configured as input in high-impedive mode.

When using FlashMagic, I would expect it to be impossible to overwrite the primary boot loader. I don't know about the design, but it doesn't seem impossible that the JTAG interface can perform an overwrite. I haven't checked how Keil implement their JTAG-programming. It was my belief that they just downloaded a small program into RAM, and then downloaded buffers data and had the tiny help program call the primary boot loader to perform a standard IAP to erase/program each sector. That is the "conventional" way to program many chips, since it isn't needed to know the electrical interface, timing or temperature compensation etc for playing directly with the flash memory.

But are you saying that you are permanently losing boards? From your first post, I got the feeling that you could get in contact with them somehow and then got them to work well if you reprogrammed them with a build based on your original startup files.

A dangerous thing is that a "stupid" program can:
- deactivate the primary boot loader from supporting FlashMagic
- deactivate the JTAG interface
- configure the chip to use an impossible PLL setting

The above would result in a chip where you are locked out, and that (because of the too high clock frequency) totally fails to run after the PLL setting has activated. The chip might get warm. But most importantly - almost everything gets "who knows what happens" when all the internal clocking runs outside specifications. Note that even the GPIO block is clocked.

Because of the above possibilities, it is very much recommended that while experimenting with PLL settings etc, not to turn on any code protect, and also to add an intentional delay loop before the PLL code. So if the chip gets overclocked, you can still use this delay time for catching it with JTAG and stop the execution.

I very much gets a feeling that you are for some reason overclocking the chip. Of course pure speculation from my side.

I only checked startup and configuration files only, without changes. I have no purpose to overclock the uC. Something has to change in both files (corrupted?) when I compiled the program. The previous version was working without problems. So, I have tried on 3 uC and they are useless now. I know that the highest level of CRP totally lock the uC memory. The problem is that I cannot reset the uC. Maybe there was problem in PLL settings and now the uC cannot enter in init mode that includes reset and primary bootloader sequence.
If the settings are the reason for this problem, then I think that the other developers had similar problem – or I’m only one that make errors.
And yes, the pins are all inputs with 2.4V at reset.

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.