Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

IAP_Flash Programming Time

IAP_Flash Programming Time

2005-04-29 by Ralf Knorr

Hi Chris,
I'm writing an IAP bootloader for the LPC2114 and test it also on an 
LPC2106 and I saw, that the flash erase takes about 100ms. I think this 
depends on the charge pumps to get the internal stable programming 
voltage for the flash. I tested erasing one or all sectors and the time 
is nearly constant.
If you use the keil IAP example there is also a for loop which takes 
about 300ms. This would explain your 400ms.
Regards, Ralf

Re: IAP_Flash Programming Time

2005-04-29 by sig5534

> This would explain your 400ms.
> Regards, Ralf

Thanks Ralf.  At least I know I am not crazy now.

Boy that really sucks.  I can understand it taking 100mS to build up a 
charge, but 300mS to burn 1024 bytes of flash?  That's 38 seconds to 
burn all 128K. Very slow.

Do you think there is anyway to do a page write kind of thing, or 
something else to reduce this time?

Thanks,  Chris.

Re: [lpc2000] Re: IAP_Flash Programming Time

2005-04-29 by Charles Manning

On Friday 29 April 2005 20:31, sig5534 wrote:
> > This would explain your 400ms.
> > Regards, Ralf
>
> Thanks Ralf.  At least I know I am not crazy now.
>
> Boy that really sucks.  I can understand it taking 100mS to build up a
> charge, but 300mS to burn 1024 bytes of flash?  That's 38 seconds to
> burn all 128K. Very slow.
>
> Do you think there is anyway to do a page write kind of thing, or
> something else to reduce this time?


You can do the whole erase as a single IAP operation. This is takes only a 
short time (~1 sec) for 128kB on an LPC2129.

Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-04-29 by Ralf Knorr

Ok,
I've just remeasured the following times on an LPC2106:

Erase sector 1-14: 100ms
Program 512 bytes starting from adress 0x2200: 250\ufffds

My xtal is 14.7456MHz and I use PLL with  multiplying factor 4, and Pll 
devider 2. VPBdivder is set to CPU clock /4.

If you want to programm whole flash (0x0-0x1DFFFF) it should take about ~1s.
Ralf

sig5534 schrieb:

> > This would explain your 400ms.
> > Regards, Ralf
>
> Thanks Ralf.  At least I know I am not crazy now.
>
> Boy that really sucks.  I can understand it taking 100mS to build up a
> charge, but 300mS to burn 1024 bytes of flash?  That's 38 seconds to
> burn all 128K. Very slow.
>
> Do you think there is anyway to do a page write kind of thing, or
> something else to reduce this time?
>
> Thanks,  Chris.
>
>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

-- 

Mit freundlichen Gr\ufffd\ufffden / Best regards
Ralf Knorr
___________________________________________________________________________________________ 

* Author: *
Dipl.-Ing. Ralf Knorr (FH)
Development: Area leader Software
Bury GmbH & Co KG
Robert-Koch-Str. 1-7
32584 L\ufffdhne
Germany
*Phone:*     +49 (0) 5732 9706 0
*Fax:*          +49 (0) 5732 9706 209
*Email:*       knorr@... <mailto:knorr@...>
*Internet:*  http://www.thb.de <http://www.thb.de/>

This email and any files transmitted with it are confidential and 
intended for the adressee only.
If you are not the adressee you may not copy, forward, disclose or 
otherwise use it, or any part of it, in any form whatever.
If you have received this e-mail in error please notify the sender and 
ensure that all copies of this e-mail and any files transmitted with it 
are deleted.

Any views or opinions represented in this e-mail are solely those of the 
author and do not necessarily represented those of Bury GmbH &Co KG or 
its affiliate companies.
___________________________________________________________________________________________

Re: Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-04-29 by sig5534

> Erase sector 1-14: 100ms
> Program 512 bytes starting from adress 0x2200: 250µs

Well I'm confused now.  I am seeing 400mS to erase one sector and prog 
1K of flash.  Are you waiting to see if the prog is actually done?  I 
am doing that, and the IAP_BUSY status does not go down until 400mS.

I can also verify that if the power goes down in 300mS the programming 
does not get completed.  The erase does, but not the prog.

So my 1024 bytes to prog is certainly taking much longer than 500uS as 
you suggest.

Any ideas?

Thanks,  Chris.

Re_ Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-04-29 by Ralf Knorr

Here is an extraction from my program:
/******************************************************************/
/* Program *data to flash_addr. number of bytes specified by size */
/* Return:  IAP error code (0 when OK)                            */
/******************************************************************/
UINT32 gIAPProgram (void *flash_addr, void *data, UINT32 size)
{
  struct iap_in  iap;                      // IAP input parameters
  UINT32 result[16];                       // IAP results

  WDMOD=0x00;                              // stop watchdog
  VICIntEnClr = 0xFFFFFFFF;                // disable all interrupts

  iap.cmd = FLASH_CMD_PREP_SEC;                            // IAP 
Command: Prepare Sectors for Write
  iap.par[0] = get_secnum (flash_addr);    // start sector
  iap.par[1] = iap.par[0];                 // end Sektor
  iap_entry (&iap, result);                // call IAP function
  if (result[0]==CMD_SUCCESS)              // an error occured?
     {
       iap.cmd = FLASH_CMD_CPY_RAM_TO_FLASH;                            
// IAP Command: Copy RAM to Flash
       iap.par[0] = (UINT32) flash_addr;  // destination-addr
       iap.par[1] = (UINT32) data;        // source-addr
       iap.par[2] = size;                       // number of bytes
       iap.par[3] = CCLK;                       // CPU clock
       iap_entry (&iap, result);                // call IAP function
     }

  gInit_Watchdog();
  VICIntEnable = gEnabledInterrupts;
  gCopySram32ToSram32BufferBinary(result,gIAP_Results,0x0000,16);
  return (result[0]);
}

UINT8 gIAP_DataBuffer[512];
//somewhere in IAP MainLoop
{
     ...

#ifdef DEBUG_INFO
CplPortPin(PORT0,Port0_06);
#endif
                  i=gIAPErase(FlashSector01_START, FlashSector14_END);// 
erasing time is ~100ms, independant if 1 or more sectors
#ifdef DEBUG_INFO
CplPortPin(PORT0,Port0_06);
#endif
     ...
#endif
#ifdef DEBUG_INFO
CplPortPin(PORT0,Port0_07);
#endif
                  i=gIAPProgram 
((FlashSector01_START+OffsetProgrammedData), gIAP_DataBuffer, sizeof 
(gIAP_DataBuffer));
#ifdef DEBUG_INFO
CplPortPin(PORT0,Port0_07);
#endif
     ...
}

Times are measured with scope on portpins
Ralf

sig5534 schrieb:

> > Erase sector 1-14: 100ms
> > Program 512 bytes starting from adress 0x2200: 250\ufffds
>
> Well I'm confused now.  I am seeing 400mS to erase one sector and prog
> 1K of flash.  Are you waiting to see if the prog is actually done?  I
> am doing that, and the IAP_BUSY status does not go down until 400mS.
>
> I can also verify that if the power goes down in 300mS the programming
> does not get completed.  The erase does, but not the prog.
>
> So my 1024 bytes to prog is certainly taking much longer than 500uS as
> you suggest.
>
> Any ideas?
>
> Thanks,  Chris.
>
>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

-- 

Mit freundlichen Gr\ufffd\ufffden / Best regards
Ralf Knorr
___________________________________________________________________________________________ 

* Author: *
Dipl.-Ing. Ralf Knorr (FH)
Development: Area leader Software
Bury GmbH & Co KG
Robert-Koch-Str. 1-7
32584 L\ufffdhne
Germany
*Phone:*     +49 (0) 5732 9706 0
*Fax:*          +49 (0) 5732 9706 209
*Email:*       knorr@... <mailto:knorr@...>
*Internet:*  http://www.thb.de <http://www.thb.de/>

This email and any files transmitted with it are confidential and 
intended for the adressee only.
If you are not the adressee you may not copy, forward, disclose or 
otherwise use it, or any part of it, in any form whatever.
If you have received this e-mail in error please notify the sender and 
ensure that all copies of this e-mail and any files transmitted with it 
are deleted.

Any views or opinions represented in this e-mail are solely those of the 
author and do not necessarily represented those of Bury GmbH &Co KG or 
its affiliate companies.
___________________________________________________________________________________________

Re: Re_ Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-04-29 by sig5534

Your code is not much different than mine, but I have a few more 
things in there for checking busy.

void attrib_RAM FlashVaderData(void) {
	Disable_INT();		// Disable INTs
   	// Prepare to erase
	flashParams[0] = IAP_CMD_PREPARE_SECTORS;   // prepare sector
(s)
  	flashParams[1] = CFG_FlashDataBlock_Sec;    // start sector
  	flashParams[2] = CFG_FlashDataBlock_Sec;    // end sector
   	callIAP();
	IOSET=IO_USB_ACK;	// toggle USB line
   	// Erase
	WaitTillFlashReady();
   	flashParams[0]=IAP_CMD_ERASE_SECTORS;
   	flashParams[1]=CFG_FlashDataBlock_Sec;
 	flashParams[2]=CFG_FlashDataBlock_Sec;
   	flashParams[3]=CCLK/1000;// CCLK in KHz
   	callIAP();
	IOCLR=IO_USB_ACK;	// toggle USB line
   	// Prepare to program
	WaitTillFlashReady();
   	flashParams[0]=IAP_CMD_PREPARE_SECTORS;
   	flashParams[1]=CFG_FlashDataBlock_Sec;
   	flashParams[2]=CFG_FlashDataBlock_Sec;
   	callIAP();
	IOSET=IO_USB_ACK;	// toggle USB line
  	//  Program
	WaitTillFlashReady();
   	flashParams[0]=IAP_CMD_COPY_RAM_TO_FLASH;
   	flashParams[1]=CFG_FlashDataBlock_Adr;	// Dst FLASH adr
   	flashParams[2]=CFG_RamDataBlock_Adr;	// Src RAM adr
   	flashParams[3]=1024;
   	flashParams[4]=CCLK/1000;				
	// CCLK in KHz
   	callIAP();
	IOCLR=IO_USB_ACK;	// toggle USB line
	WaitTillFlashReady();
	Enable_INT();		// Enable INTs
}

Essentially here are the 4 steps and their timing:

IAP_CMD_PREPARE_SECTORS     (<4mS)
IAP_CMD_ERASE_SECTORS       (400mS)
IAP_CMD_PREPARE_SECTORS     (<4mS)
IAP_CMD_COPY_RAM_TO_FLASH   (<8mS)

I am simply toggling a line IO_USB_ACK on the board and sampling with 
the scope.

So all of my time is spent in doing the erase task on this single 
sector - 400mSec.  That's the problem.

Why do you think yours is 100mS and mine is 400mS?

Thanks,  Chris.

Re: Re_ Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-04-29 by sig5534

Well I think I found an answer.  My system is using a 24MHz xtal, and I 
am using the PLL to up it to 48MHz.

As you see I was div the 48MHz by 1000 to give IAP the value in kHz.  
So I tried div the 48MHz by 2000 instead:

The erase time dropped from 400mS to 200mS. 

Obviously this clock parameter is directly affecting the timing.

Is it suppose to be the CCLK(48MHz) or the XtalOsc(24MHz) ? 

If your's is coming out at 100mS, seems like you would have to have yet 
another ratio, say div by 4.

What is your PLL freq, Xtal Freq, and the value you are putting into 
the IAP param?
 
Thanks,  Chris.

Re_ Re_ Re_ [lpc2000] Re_ IAP_Flash Programming Time

2005-05-02 by Ralf Knorr

My XTAL freq is 14.7456 MHz
Pll factor is 4 -> CPUclk=58,9824MHz
PLL div is 2 ->  29,4912MHz
VPB div is 4 -> 14.7456MHz

But I saw maybe a problem in software, because I set the value to 
program flash to XTALfreq /1000.
I've to recheck it when I'll finish my bootloader.
Generally, the correct factor would be the CPUclk.
Regards, Ralf

sig5534 schrieb:

> Well I think I found an answer.  My system is using a 24MHz xtal, and I
> am using the PLL to up it to 48MHz.
>
> As you see I was div the 48MHz by 1000 to give IAP the value in kHz. 
> So I tried div the 48MHz by 2000 instead:
>
> The erase time dropped from 400mS to 200mS.
>
> Obviously this clock parameter is directly affecting the timing.
>
> Is it suppose to be the CCLK(48MHz) or the XtalOsc(24MHz) ?
>
> If your's is coming out at 100mS, seems like you would have to have yet
> another ratio, say div by 4.
>
> What is your PLL freq, Xtal Freq, and the value you are putting into
> the IAP param?
>
> Thanks,  Chris.
>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

-- 

Mit freundlichen Gr\ufffd\ufffden / Best regards
Ralf Knorr
___________________________________________________________________________________________ 

* Author: *
Dipl.-Ing. Ralf Knorr (FH)
Development: Area leader Software
Bury GmbH & Co KG
Robert-Koch-Str. 1-7
32584 L\ufffdhne
Germany
*Phone:*     +49 (0) 5732 9706 0
*Fax:*          +49 (0) 5732 9706 209
*Email:*       knorr@... <mailto:knorr@...>
*Internet:*  http://www.thb.de <http://www.thb.de/>

This email and any files transmitted with it are confidential and 
intended for the adressee only.
If you are not the adressee you may not copy, forward, disclose or 
otherwise use it, or any part of it, in any form whatever.
If you have received this e-mail in error please notify the sender and 
ensure that all copies of this e-mail and any files transmitted with it 
are deleted.

Any views or opinions represented in this e-mail are solely those of the 
author and do not necessarily represented those of Bury GmbH &Co KG or 
its affiliate companies.
___________________________________________________________________________________________

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.