320F2811/2812 use part of the program flash as a data flash
in [Design]
|
Prev: dsPIC33f and SPI,SSEN too short
Next: Strange waveform
From: Vladimir Vassilevsky on 27 Mar 2010 12:56 mook johnson wrote: > Can the a section of the program flash be written to, by the embedded code, > for storing things like calibration data that would are loaded serially once > the device is in service? > > I need these to be loaded via the SCI or SPI and written to internal > non-volatile memory. These valued may change over the life of the device so > the OTP is not a clean option. It can be done of that is the only option > but not a clean as I'd like. > > Trying to avoid adding a serial eprom for those purposes. P.S. IIRC the TI code composer includes so-called "flash API". This is SRAM loadable module that you can use from your program. It is rather inconvenient and dumb, however it can do the job. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: mook johnson on 27 Mar 2010 14:14 "Vladimir Vassilevsky" <nospam(a)nowhere.com> wrote in message news:j7Kdneu6ybArpTPWnZ2dnUVZ_qudnZ2d(a)giganews.com... > > > mook johnson wrote: > >> Can the a section of the program flash be written to, by the embedded >> code, for storing things like calibration data that would are loaded >> serially once the device is in service? >> >> I need these to be loaded via the SCI or SPI and written to internal >> non-volatile memory. These valued may change over the life of the device >> so the OTP is not a clean option. It can be done of that is the only >> option but not a clean as I'd like. >> >> Trying to avoid adding a serial eprom for those purposes. > > P.S. IIRC the TI code composer includes so-called "flash API". This is > SRAM loadable module that you can use from your program. It is rather > inconvenient and dumb, however it can do the job. > > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com Thanks!
From: Robert Baer on 28 Mar 2010 13:48 mook johnson wrote: > Can the a section of the program flash be written to, by the embedded code, > for storing things like calibration data that would are loaded serially once > the device is in service? > > I need these to be loaded via the SCI or SPI and written to internal > non-volatile memory. These valued may change over the life of the device so > the OTP is not a clean option. It can be done of that is the only option > but not a clean as I'd like. > > Trying to avoid adding a serial eprom for those purposes. > > > > Know nothing about the part. BUT..can *part* of the program memory be written (externally) without disturbing other parts? If so, that is the work-around: have the program (under strict conditions) re-program a specific program memory section. Natually, this ties up some pins for output, some for input (programming) and one or two for control.
From: MooseFET on 28 Mar 2010 12:11 On Mar 27, 9:07 am, "mook johnson" <m...(a)mook.net> wrote: > Can the a section of the program flash be written to, by the embedded code, > for storing things like calibration data that would are loaded serially once > the device is in service? > > I need these to be loaded via the SCI or SPI and written to internal > non-volatile memory. These valued may change over the life of the device so > the OTP is not a clean option. It can be done of that is the only option > but not a clean as I'd like. > > Trying to avoid adding a serial eprom for those purposes. How often do the numbers need to change, what is the expected life of the device and how much OTP space do you have free? If you can write bits but not erase them, you can use one bit to say that this number is no longer the one to use.
From: mook johnson on 28 Mar 2010 13:21
"MooseFET" <kensmith(a)rahul.net> wrote in message news:8a931810-13ed-42ac-952b-c5350f55a2d9(a)t34g2000prm.googlegroups.com... On Mar 27, 9:07 am, "mook johnson" <m...(a)mook.net> wrote: > Can the a section of the program flash be written to, by the embedded > code, > for storing things like calibration data that would are loaded serially > once > the device is in service? > > I need these to be loaded via the SCI or SPI and written to internal > non-volatile memory. These valued may change over the life of the device > so > the OTP is not a clean option. It can be done of that is the only option > but not a clean as I'd like. > > Trying to avoid adding a serial eprom for those purposes. How often do the numbers need to change, what is the expected life of the device and how much OTP space do you have free? If you can write bits but not erase them, you can use one bit to say that this number is no longer the one to use. These will change infrequently. Maybe 10 times over the life of the device. Most of the time it will never change. The data that goes in there will only be 20 words long so one thought was the put a preamble code on the table and everytime a new update is sent it appends the OTP space with the new set of parameters. The application code reads linearly down the OTP address space and finds the last table and loads that as the latest set of parameters. It shoud be fine, I jsut have having a finite number of times write to the address space. I guess I still have that limitation with flash dou to the maximum number of writes limited to 1000. I think I'll do the OTP for now. thanks |