Lpc2000

Hi, Bob,

Thank you for your help.

It turned out the problem was caused by a buffer overflow. My own 
fault. Your tip helps.

Best regards !

Greg


--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@...> 
wrote:
>
> Hi Greg,
> 
> one thing that I have seen before that ended up with the same 
symptoms
> your are describing is an IAP call with the wrong frequency. What 
I am
> referring to is you boot up let's say with 14.756 MHz and do some 
IAP
> calls, then you enable the PLL and still call IAP with the same 
14.756
> although now it is 59 MHz. 
> I have seen the programming work "most of the time" but one bit or 
one
> byte being incorrect.
> 
> May be this helps, Bob
> 
> --- In lpc2000@yahoogroups.com, "fl429" <fl429@> wrote:
> >
> > Hi, Folks,
> > 
> > Hopefully, someone can shed some light to this. Thanks.
> > 
> > First, this is not my first app on the LPC2138. I had no trouble 
> > before, until I use IAP in this one.
> > 
> > The IAP calls seem working OK. No error reported. Flash memory 
does 
> > program as expected, as far as I can see.
> > 
> > But, a simle C structure in one of the functions now behaves 
wierdly 
> > SOMETIMES. This is called repeatedly in a loop.
> > 
> > switch(m_CmdTmp) {
> > case 1:
> >     ..... codes here
> >     m_CmdTmp=2;
> >     break;
> > case 2:
> >     if(!Started()) {
> >          Starting();         <<====== Point 1
> >          // some other stuff ... here
> >          m_CmdTmp=3;
> >     }
> >     break;
> > case 3:
> >     ...
> >     break;
> > }
> > 
> > After some poking around, I found I am at Point 1 while m_CmdTmp 
> > already equals 3 (m_CmdTmp=3).
> > There is no interrupts changing the value of m_CmdTmp behind my 
> > back ! m_CmdTmp is supposed to progress ONLY in this switch 
routine.
> > 
> > I tried to change stack sizes to no avail. I reserved 256 bytes 
from 
> > the TOP of SRAM (0x400007e00 and up) from being used by this 
APP. 
> > No, I still have this problem.
> > 
> > Any ideas ?
> > 
> > Thanks a lot,
> > 
> > Greg
> >
>