<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>reset</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/35545/reset</link><description> 
I am using uVision4 and have an LPC2103. 
After each reset the module desn&amp;#39;t start directly (after 2 or 3
attempt) can you help me. 
 </description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: reset</title><link>https://community.arm.com/thread/64662?ContentTypeID=1</link><pubDate>Wed, 20 Apr 2016 09:37:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:47bd0e04-5406-40c2-ad7e-227da67afe0a</guid><dc:creator>Stephen Hellriegel</dc:creator><description>&lt;p&gt;&lt;p&gt;
I agree with Per&amp;#39;s comments.&lt;br /&gt;
Looking at your code, you are doing low level register manipulation
that is normally handled by Startup.s&lt;br /&gt;
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.&lt;/p&gt;

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

&lt;p&gt;
There is a file called Startup.s. This file is specific to the
LPC2103 device you are working with.&lt;/p&gt;

&lt;p&gt;
Copy it into your project, and add it to your workspace. You can
then click on the &amp;quot;Configuration Wizard&amp;quot; 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.&lt;/p&gt;

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

&lt;p&gt;
You are on the hook for peripheral initialization other than
clocking.&lt;br /&gt;
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)&lt;/p&gt;

&lt;p&gt;
You may be mis-configuring the peripheral clocks and hanging the
processor.&lt;/p&gt;

&lt;p&gt;
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&amp;#39;t need to touch MEMMAP unless
you really understand the VIC and interrupt indirection and are doing
a bootloader based application.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/108750?ContentTypeID=1</link><pubDate>Wed, 20 Apr 2016 09:16:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:41fef669-3f18-4290-b6f2-c72ad68b67fd</guid><dc:creator>fazil merok</dc:creator><description>&lt;p&gt;&lt;p&gt;
Problem solved&lt;/p&gt;

&lt;p&gt;
&lt;a href="https://rowley.zendesk.com/hc/en-us/articles/210032983"&gt;rowley.zendesk.com/.../210032983&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
thanx for you&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/108737?ContentTypeID=1</link><pubDate>Wed, 20 Apr 2016 09:02:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b12c27a7-6865-4d0a-adcc-608d7c4b8ca1</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Don&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
So some programs can survive better if the reset pin isn&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
So - a correct reset but bad software can (but maybe not always)
give random failures.&lt;br /&gt;
And correct software with a bad reset can (but maybe not always) give
random failures.&lt;/p&gt;

&lt;p&gt;
In short - you need to make sure that both your code and your
reset signal is correct.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/83129?ContentTypeID=1</link><pubDate>Wed, 20 Apr 2016 01:38:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f6bf0c68-5e67-42ce-96ca-029ed11552a1</guid><dc:creator>fazil merok</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you for answering&lt;br /&gt;
The problem is not in hard because I put another hex file and it
works correctly.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/83130?ContentTypeID=1</link><pubDate>Wed, 20 Apr 2016 01:28:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1abbc0f6-c242-4357-85d9-5d5dc891d42e</guid><dc:creator>fazil merok</dc:creator><description>&lt;p&gt;&lt;p&gt;
I do not think it&amp;#39;s a reset problem.&lt;br /&gt;
For example:&lt;br /&gt;

&lt;a href="http://electroblogs.weebly.com/uploads/1/0/0/2/10025574/8478695_orig.png"&gt;electroblogs.weebly.com/.../8478695_orig.png&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;pre&gt;
int main()
{
PLL_Init();
PINSEL0=0x00000005;
PINSEL1=0x00000000;
IO0DIR = 0xFFFFBFFD;
UART0_init();
IO0SET |= (1&amp;lt;&amp;lt;13);
IO0SET |= (1&amp;lt;&amp;lt;17);
IO0SET |= (1&amp;lt;&amp;lt;21);

while(1)
{
/*
code
*/
}
&lt;/pre&gt;

&lt;p&gt;
&lt;/p&gt;

&lt;pre&gt;
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 &amp;lt;&amp;lt; 5);
#endif
#if (Fcco / Fcclk) == 4
    PLLCFG = ((Fcclk / Fosc) - 1) | (1 &amp;lt;&amp;lt; 5);
#endif
#if (Fcco / Fcclk) == 8
    PLLCFG = ((Fcclk / Fosc) - 1) | (2 &amp;lt;&amp;lt; 5);
#endif
#if (Fcco / Fcclk) == 16
    PLLCFG = ((Fcclk / Fosc) - 1) | (3 &amp;lt;&amp;lt; 5);
#endif


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


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

&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/64655?ContentTypeID=1</link><pubDate>Tue, 19 Apr 2016 13:06:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5f4c01fa-b8f9-4f9b-ab58-3e2316f8e687</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
Consider a proper reset circuit that holds NRESET low for a few
hundred milliseconds to assure a clean/consistent reset&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: reset</title><link>https://community.arm.com/thread/69547?ContentTypeID=1</link><pubDate>Tue, 19 Apr 2016 10:23:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cf4e3f28-7728-4470-9350-2e507f8fd75c</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Don&amp;#39;t you think this sounds more like a reset issue?&lt;/p&gt;

&lt;p&gt;
So how have you made sure your processor gets a good reset
signal?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>