IAP Samples?

Started by Greg Esmond November 18, 2006
I posted a few days ago about a need to store variables in flash, and Saurabh suggested using IAP (thanks!). However, I can't figure IAP out. I found an app in the files section that creates a pseudo EEPROM in flash using IAP, but it would be helpful to see some more examples. Any suggestions?

What I need to do is store, update, and read an array of 8 bit numbers. As you can tell from reading this, I'm new to this. BTW, I'm using a 2129.

Thanks,

Greg

An Engineer's Guide to the LPC2100 Series

--- In l..., "Greg Esmond" wrote:
>
> I posted a few days ago about a need to store variables in flash,
and Saurabh suggested using IAP (thanks!). However, I can't figure
IAP out. I found an app in the files section that creates a pseudo
EEPROM in flash using IAP, but it would be helpful to see some more
examples. Any suggestions?
>
> What I need to do is store, update, and read an array of 8 bit
numbers. As you can tell from reading this, I'm new to this. BTW,
I'm using a 2129.
>
> Thanks,
>
> Greg
>

You can search the archives here. The subject comes up all the time.
Usually followed a day or so later by "Oops, I erased the bootloader,
now what do I do?"

The IAP process obviously works, no question about it. However, given
all the grief reported here, I would give serious consideration to
using an EEPROM like the 24C256. A small 32k x 8 bit EEPROM hanging
on the I2C bus.

There are a number of minimum block size and time constraint issues to
solve. I haven't used IAP so I have no idea what I'm talking about.
Just search, read and make a choice.

Richard
At 08:35 PM 11/18/2006 -0500, Greg Esmond wrote:
>I posted a few days ago about a need to store variables in flash, and
>Saurabh suggested using IAP (thanks!). However, I can't figure IAP
>out. I found an app in the files section that creates a pseudo EEPROM in
>flash using IAP, but it would be helpful to see some more examples. Any
>suggestions?
>
>What I need to do is store, update, and read an array of 8 bit
>numbers. As you can tell from reading this, I'm new to this. BTW, I'm
>using a 2129.

How much data? How frequently updated? And how long can you devote to
updating them?

Frequent updates would suggest another technology would work better. Using
code storage for data is always somewhat risky.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
The thing is that I really don't want to design much custom hardware. Adding an EEPROM via I2C seems like a LOT more trouble than using IAP. I just need to store 200 bytes from an array. Those 200 bytes will likely be modified 100 times a year. The time that the data needs to be stored is a time that processing speed is a non-issue.

Honestly, I'm REALLY disappointed that I can't just attach a tiny battery to the SRAM to maintain the RAM data for a year per battery. That is how my last microcontroller board worked. :(

Greg Esmond
Prestige Comforce Professional Services
Home: (972) 529-6465
Cell: (972) 658-4061

________________________________

From: l... on behalf of Robert Adsett
Sent: Sat 11/18/2006 9:04 PM
To: l...
Subject: Re: [lpc2000] IAP Samples?

At 08:35 PM 11/18/2006 -0500, Greg Esmond wrote:
>I posted a few days ago about a need to store variables in flash, and
>Saurabh suggested using IAP (thanks!). However, I can't figure IAP
>out. I found an app in the files section that creates a pseudo EEPROM in
>flash using IAP, but it would be helpful to see some more examples. Any
>suggestions?
>
>What I need to do is store, update, and read an array of 8 bit
>numbers. As you can tell from reading this, I'm new to this. BTW, I'm
>using a 2129.

How much data? How frequently updated? And how long can you devote to
updating them?

Frequent updates would suggest another technology would work better. Using
code storage for data is always somewhat risky.

Robert

http://www.aeolusdevelopment.com/

>From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
At 11:54 PM 11/18/2006 -0500, Greg Esmond wrote:
>The thing is that I really don't want to design much custom
>hardware. Adding an EEPROM via I2C seems like a LOT more trouble than
>using IAP.

Other way around. The overhead for writing to the flash you are running
from is high on any processor/flash combination I've dealt with. EEProm
via SPI is quite low, FRAM via SPI is even lower. IIC adds some protocol
complexity over SPI but still substantially less than IAP.

If adding an SPI FRAM to your board is taxing how are you getting any
interface done? All that is required is three lines to the micro, a few
pull-ups, a despiking cap and power., less than an RS-232 or 485 interface
requires

Until you are shipping multiple thousands per year I don't see the cost of
the external storage exceeding the engineering and risk premium of the IAP
solution. Even then I'd want to be sure it was worth the trouble. My
suspicion is that the hold up detect circuitry will approach a substantial
portion of the cost of a small FRAM. You should have power fail detect
circuitry in either case.

> I just need to store 200 bytes from an array. Those 200 bytes will
> likely be modified 100 times a year. The time that the data needs to be
> stored is a time that processing speed is a non-issue.

Sounds like it, just remember the processor is essentially stopped while
doing the update and the result if you lose power part way through the
update is undefined, almost anything could happen including corrupting
areas not being programmed. I suspect the later is unlikely given the
unlock sequence required for IAP.

If this was for one time calibration/configuration info I'd suggest setting
it up when you program the application.

>Honestly, I'm REALLY disappointed that I can't just attach a tiny battery
>to the SRAM to maintain the RAM data for a year per battery. That is how
>my last microcontroller board worked. :(

Define tiny..... :)
Robert

Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
I guess I need to overcome my fear and laziness about hardware issues. I am NOT a hardware guy at all, and this is a home-grown project. I would much rather accomplish something via software than hardware. I'm using 2 off-the-shelf microcontroller boards linked together via serial right now because I can't figure out a way to add a DAC to my primary board. Honestly, I can't figure out how you guys are able to do it either with these friggin' tiny ass ICs that can't be added to a prototype area. The DACs I've found require a magnifying glass to see the pins! Are EEPROM's any different?

Greg Esmond
Prestige Comforce Professional Services
Home: (972) 529-6465
Cell: (972) 658-4061

________________________________

From: l... on behalf of Robert Adsett
Sent: Sun 11/19/2006 12:43 PM
To: l...
Subject: RE: [lpc2000] IAP Samples?

At 11:54 PM 11/18/2006 -0500, Greg Esmond wrote:
>The thing is that I really don't want to design much custom
>hardware. Adding an EEPROM via I2C seems like a LOT more trouble than
>using IAP.

Other way around. The overhead for writing to the flash you are running
from is high on any processor/flash combination I've dealt with. EEProm
via SPI is quite low, FRAM via SPI is even lower. IIC adds some protocol
complexity over SPI but still substantially less than IAP.

If adding an SPI FRAM to your board is taxing how are you getting any
interface done? All that is required is three lines to the micro, a few
pull-ups, a despiking cap and power., less than an RS-232 or 485 interface
requires

Until you are shipping multiple thousands per year I don't see the cost of
the external storage exceeding the engineering and risk premium of the IAP
solution. Even then I'd want to be sure it was worth the trouble. My
suspicion is that the hold up detect circuitry will approach a substantial
portion of the cost of a small FRAM. You should have power fail detect
circuitry in either case.

> I just need to store 200 bytes from an array. Those 200 bytes will
> likely be modified 100 times a year. The time that the data needs to be
> stored is a time that processing speed is a non-issue.

Sounds like it, just remember the processor is essentially stopped while
doing the update and the result if you lose power part way through the
update is undefined, almost anything could happen including corrupting
areas not being programmed. I suspect the later is unlikely given the
unlock sequence required for IAP.

If this was for one time calibration/configuration info I'd suggest setting
it up when you program the application.

>Honestly, I'm REALLY disappointed that I can't just attach a tiny battery
>to the SRAM to maintain the RAM data for a year per battery. That is how
>my last microcontroller board worked. :(

Define tiny..... :)

Robert

Another sign of the end of civilization, our technical magazines are
getting chatty
>From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
--- In l..., "Greg Esmond" wrote:
>
> I guess I need to overcome my fear and laziness about hardware
>issues. I am NOT a hardware guy at all, and this is a home-grown
>project. I would much rather accomplish something via software than
>hardware. I'm using 2 off-the-shelf microcontroller boards linked
>together via serial right now because I can't figure out a way to add
>a DAC to my primary board. Honestly, I can't figure out how you guys
>are able to do it either with these friggin' tiny ass ICs that can't
>be added to a prototype area. The DACs I've found require a
>magnifying glass to see the pins! Are EEPROM's any different?

No, surface mount parts including EEPROMS are getting smaller all
the time. All this is driven mostly by the desire of the public
to have cell phones implanted directly into their ears.

Sounds like you need a nice adapter/breakout board for your DAC.
You need to find out what package it is in and then look for the
appropriate board. But be prepared to pay! these things can cost
quite a bit more then your typical 99 cent part.

Google
"SOIC DIP adapter board" or "SOP DIL adapter board",
you need to substitute SOIC and SOP for your DAC package name.

To solder these things I would not recommend magnifying glass,
personally I am using stereo zoom microscope.

elektrknight
>
> Greg Esmond
> Prestige Comforce Professional Services
> Home: (972) 529-6465
> Cell: (972) 658-4061
>
> ________________________________
>
> From: l... on behalf of Robert Adsett
> Sent: Sun 11/19/2006 12:43 PM
> To: l...
> Subject: RE: [lpc2000] IAP Samples?
>
> At 11:54 PM 11/18/2006 -0500, Greg Esmond wrote:
> >The thing is that I really don't want to design much custom
> >hardware. Adding an EEPROM via I2C seems like a LOT more trouble than
> >using IAP.
>
> Other way around. The overhead for writing to the flash you are running
> from is high on any processor/flash combination I've dealt with. EEProm
> via SPI is quite low, FRAM via SPI is even lower. IIC adds some
protocol
> complexity over SPI but still substantially less than IAP.
>
> If adding an SPI FRAM to your board is taxing how are you getting any
> interface done? All that is required is three lines to the micro, a few
> pull-ups, a despiking cap and power., less than an RS-232 or 485
interface
> requires
>
> Until you are shipping multiple thousands per year I don't see the
cost of
> the external storage exceeding the engineering and risk premium of
the IAP
> solution. Even then I'd want to be sure it was worth the trouble. My
> suspicion is that the hold up detect circuitry will approach a
substantial
> portion of the cost of a small FRAM. You should have power fail detect
> circuitry in either case.
>
> > I just need to store 200 bytes from an array. Those 200 bytes will
> > likely be modified 100 times a year. The time that the data needs
to be
> > stored is a time that processing speed is a non-issue.
>
> Sounds like it, just remember the processor is essentially stopped
while
> doing the update and the result if you lose power part way through the
> update is undefined, almost anything could happen including corrupting
> areas not being programmed. I suspect the later is unlikely given the
> unlock sequence required for IAP.
>
> If this was for one time calibration/configuration info I'd suggest
setting
> it up when you program the application.
>
> >Honestly, I'm REALLY disappointed that I can't just attach a tiny
battery
> >to the SRAM to maintain the RAM data for a year per battery. That
is how
> >my last microcontroller board worked. :(
>
> Define tiny..... :)
>
> Robert
>
> Another sign of the end of civilization, our technical magazines are
> getting chatty
> From an EETimes product descriptions 2006/08/09
> ".... systems that can sample gobs of inputs simultaneously"
> Now just what is the technical definition for gobs again?
> http://www.aeolusdevelopment.com/
>
>
#include

#define LOAD 0x00 //define the load command
#define EP 0x68 // define the eraseprogram
command

extern unsigned char code *fshptr;
//bit errflg_iap;
//======================================================================//For writing byte in Flash
//I/P dptr which contains addr of flash, r7 (data)
//O/P errflg_iap (set if byte does not written)
//*******************************************************************
******
// Function : ()
// Input : None
// Return : None
// Description :
//*******************************************************************
*******

write()
{
unsigned char i;
EA = 0; // This is must
FMCON = LOAD;
FMADRH = lower_addr_byte;
FMADRL = higher_addr_byte;

for (i=0;i {FMDATA = data[i]
//FMDATA is buffer of 16 bytes that stores data to be writn on flash
}

FMCON = EP; // this will write data in FMDATA to flash

/*if (FMCON & 0x8F)
errflg_iap = 1; // set error flag on error
else
errflg_iap= 0; //clear on no error

*/
EA = 1;
}
At 12:04 AM 11/20/2006 -0500, Greg Esmond wrote:
>I guess I need to overcome my fear and laziness about hardware issues. I
>am NOT a hardware guy at all, and this is a home-grown project. I would
>much rather accomplish something via software than hardware. I'm using 2
>off-the-shelf microcontroller boards linked together via serial right now
>because I can't figure out a way to add a DAC to my primary
>board. Honestly, I can't figure out how you guys are able to do it either
>with these friggin' tiny ass ICs that can't be added to a prototype
>area. The DACs I've found require a magnifying glass to see the
>pins! Are EEPROM's any different?
Through hole DACs like these maybe?

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?&familyId92&uiTemplateId=NODE_STRY_PGE_T&sectionId=null&tabId=null&appId=null&virtualTreeURL=D_PARAMETER_2000084|EQ|12&viewDeviceCallingPage=null&totalCountU&showAdditionalParameters=yes&parameter$80904684&parameter$80904691&parameter$80904454&parameter$80904472&parameter$80904519&parameter$80904545&rpc=D_PARAMETER_2000084|EQ|12|0&lc 00084&lc 00112&lc 00596&lc#00989&lc 00116&lc 00376&lc 00089&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=&sortMode=&searchPaths00392&pageId=undefined&templateId=0&navigationId=0&family=analog&paramTable=no&military=no&&uiTemplateId=NODE_STRY_PGE_T&sectionId=null&tabId=null&appId=null&virtualTreeURL=D_PARAMETER_2000084|EQ|12&viewDeviceCallingPage=null&resetCompare=true#sdp

Long URL Go to TI's site and the parametric search in data convertors
allows you to include package type in the search criteria.
Unfortunately Ramtron appears to have switched entirely to SM but through
hole EE is readily available.

EG Atmel AT93C46A-10PI-2.7

If I am laying out a board I actually usually prefer SM. I find them as
easy or easier to deal with, at least until you get to fine pitches.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."