Lpc2000

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

Can you try declaring your m_CmdTmp as static? This will remove it 
from the local registers into a specific memory location. Volatile is 
even better. This might give you some clues either if it works or it 
does not.

Guille

--- 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
>

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
>

Well. I guess it was not IAP after I put a dummy function in the 
place of the IAP Call.

I tried to use a static variable. The problem was still there. BTW, I 
am using GCC 3.4.4. It is a cpp program.

I looked at the assembly. It may have something to do with R11, the 
frame pointer. The problem seems appear when under stress. OK, I am 
working on my own bootloader. Bootloading a really small code, it 
works ok. When loading a few KBytes, it shows up. 

I can get around the symptom by a simple if statement, such as,

switch(m_CmdStep) {
case 1:
  ...
  break;
case 2:
  if(!Started()) {
     if(m_CmdStep==2)
        Starting();
     m_CmdStep=3;
  }
  break;
case 3:
  ...
  break;
};

But I fear I hid the real problem. Any ideas ?

Thanks for all replies.

Greg   

--- 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
>

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. 
>  
>

Is that how you read the manual?  I thought that "system clock" was 
referring to that of the external clocking rate, not that as the PLL clock?

Do I have to use the PLL clock rate for this?

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Tom,

I am absolutely certain about this, it has been verified with Philips.
Each IAP call needs to have the frequence the device is currently
running at. If the PLL is active the parameter needs to be PLL*ext. Freq. 

The "funny" part is, it works ALMOST all the time even with the wrong
frequency.

Bob

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>
> 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. 
> >  
> >
> 
> Is that how you read the manual?  I thought that "system clock" was 
> referring to that of the external clocking rate, not that as the PLL
clock?

> 
> Do I have to use the PLL clock rate for this?
> 
> Regards,
> 
> TomW
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

lpc2100_fan wrote:

>Tom,
>
>I am absolutely certain about this, it has been verified with Philips.
>Each IAP call needs to have the frequence the device is currently
>running at. If the PLL is active the parameter needs to be PLL*ext. Freq. 
>
>The "funny" part is, it works ALMOST all the time even with the wrong
>frequency.
>
>  
>
LOL, thanks!

TomW



>Bob
>
>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>  
>
>>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. 
>>> 
>>>
>>>      
>>>
>>Is that how you read the manual?  I thought that "system clock" was 
>>referring to that of the external clocking rate, not that as the PLL
>>    
>>
>clock?
>  
>
>>Do I have to use the PLL clock rate for this?
>>
>>Regards,
>>
>>TomW
>>
>>
>>-- 
>>Tom Walsh - WN3L - Embedded Systems Consultant
>>http://openhardware.net, http://cyberiansoftware.com
>>"Windows? No thanks, I have work to do..."
>>----------------------------------------------------
>>
>>    
>>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Bob,

Those who feel offended when I point out deficiencies in boot loader 
implementation please do not read further.

I found that the need to specify CPU clock frequency at run-time IMO causes 
a number of problems including the one you pointed out.  Sometimes CPU 
clock is changed at runtime based for power considerations you have to keep 
track of this for IAP calls.

Flash programming requires three parameters relating to CPU clock.  The 
first two of these, relating to writing to LPC timing registers #1 and #2 
appear to accept a large degree of variation, at least 1:4 in my case.

I did away with the need for CPU clock at the third instance where boot 
loader IAP implementation uses CPU clock parameter.  After issuing a flash 
command, it is possible to determine when this is complete by examining LPC 
flash controller status register.  I do this, but boot loader code does 
not.  Instead, it waits for a programmed number of cycles based on the 
supplied clock frequency.

When the programmer inadvertently supplies a low clock speed, the IAP call 
terminates before the flash controller is ready, and you can see that what 
happens after this is indeterminate.  Worse, it can permanently destroy the 
part.

It appears that for the timing register parameters accept quite a large 
variance, at least 1 to 4 variance in my case.  If Philips would disclose 
what are these limits are, it is possible one could do away with need for 
CPU clock frequency altogether for IAP or ISP calls.

My experience is limited to boards with 14M7456 crystals and with  PLL 
speeds between 1 to 4 times that.

Regards,

Jaya

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@...> wrote:
 >
 > Tom,
 >
 > I am absolutely certain about this, it has been verified with Philips.
 > Each IAP call needs to have the frequence the device is currently
 > running at. If the PLL is active the parameter needs to be PLL*ext. Freq.
 >
 > The "funny" part is, it works ALMOST all the time even with the wrong
 > frequency.
 >
 > Bob

Send instant messages to your online friends http://au.messenger.yahoo.com

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
> >
>