reset

Don't you think this sounds more like a reset issue?

So how have you made sure your processor gets a good reset signal?

Consider a proper reset circuit that holds NRESET low for a few hundred milliseconds to assure a clean/consistent reset

I do not think it's a reset problem.
For example:
electroblogs.weebly.com/.../8478695_orig.png

I am beginner in programming in Keil and I want to know if there is a problem with code (main.c or startup) or at target.

int main()
{
PLL_Init();
PINSEL0=0x00000005;
PINSEL1=0x00000000;
IO0DIR = 0xFFFFBFFD;
UART0_init();
IO0SET |= (1<<13);
IO0SET |= (1<<17);
IO0SET |= (1<<21);

while(1)
{
/*
code
*/
}

void PLL_Init(void)
{
#ifdef __DEBUG_RAM
    MEMMAP = 0x2;
#endif

#ifdef __DEBUG_FLASH
    MEMMAP = 0x1;
#endif

#ifdef __IN_CHIP
    MEMMAP = 0x1;
#endif


    PLLCON = 1;
#if (Fpclk / (Fcclk / 4)) == 1
    VPBDIV = 0;
#endif
#if (Fpclk / (Fcclk / 4)) == 2
    VPBDIV = 2;
#endif
#if (Fpclk / (Fcclk / 4)) == 4
    VPBDIV = 1;
#endif

#if (Fcco / Fcclk) == 2
    PLLCFG = ((Fcclk / Fosc) - 1) | (0 << 5);
#endif
#if (Fcco / Fcclk) == 4
    PLLCFG = ((Fcclk / Fosc) - 1) | (1 << 5);
#endif
#if (Fcco / Fcclk) == 8
    PLLCFG = ((Fcclk / Fosc) - 1) | (2 << 5);
#endif
#if (Fcco / Fcclk) == 16
    PLLCFG = ((Fcclk / Fosc) - 1) | (3 << 5);
#endif


    PLLFEED = 0xaa;
    PLLFEED = 0x55;
    while((PLLSTAT & (1 << 10)) == 0);
    PLLCON = 3;
    PLLFEED = 0xaa;
    PLLFEED = 0x55;


        VICIntEnClr = 0xffffffff;
        VICVectAddr = 0;
        VICIntSelect = 0;
        }

Thank you for answering
The problem is not in hard because I put another hex file and it works correctly.

Don't bet on that - a correct reset pulse will guarantee that the chip is in a known state. A too short reset pulse will leave the processor in an unknown state - and it can matter what state it was in before the too short reset.

So some programs can survive better if the reset pin isn't correctly handled. With a bad reset signal, the CPU core might be reset while some interrupt source might not have enough time to properly reset - and the end result is that you might get an interrupt that jumps into undefined memory.

So - a correct reset but bad software can (but maybe not always) give random failures.
And correct software with a bad reset can (but maybe not always) give random failures.

In short - you need to make sure that both your code and your reset signal is correct.

Problem solved

rowley.zendesk.com/.../210032983

thanx for you

I agree with Per's comments.
Looking at your code, you are doing low level register manipulation that is normally handled by Startup.s
Your function PLL_Init() is not needed for proper operation; everything that is done in that function is handled by the reset signal or the Startup.s configuration.

Look in your installed Keil directory for Arm\Boards\Keil\MCB2103\Blinky
(I am a codgy coder, my install is at C:\Keil, yours is likely C:\KeilV5)

There is a file called Startup.s. This file is specific to the LPC2103 device you are working with.

Copy it into your project, and add it to your workspace. You can then click on the "Configuration Wizard" at the bottom of the source editor window and get a menu to configure things like the myriad of peripheral clocks and CPU clock rate.

Using the supplied Startup.s will get your device clocks configured and booting reliably every time.
Startup.s also contains the C-runtime (CRT) (zeroing of RAM, setup of stack, supervisor mode, jump to main()), so if you don't have it, your code will never appear to work.

You are on the hook for peripheral initialization other than clocking.
You are on the hook to manage the PCONP register (you have to power up a peripheral before you can use it unless it is one of the set of peripherals which are enabled at power on reset)

You may be mis-configuring the peripheral clocks and hanging the processor.

Note, you are messing with MEMMAP. Normally the only time you do that is if you are working with an embedded custom bootloader. Since you mention you are new to Keil, I suggest you get your project running without a bootloader. You don't need to touch MEMMAP unless you really understand the VIC and interrupt indirection and are doing a bootloader based application.

One last hint, check the P0.14 pin to make sure it is high during/just after reset. Otherwise at you will go into an embedded bootloader.

One really last hint, make sure the MAM (flash memory acceleration module) is correctly configured for your CPU clock rate (another option in startup.s). Note some versions of startup.s you enter the desired divisor, and it automatically adds or subtracts 1 for you before storing into the MAM. So just double check what is processed by the editor into startup.s actually matches what you want. This bit me hard back in 2007.