Storing data in flash: HCS12

Hi, I'm planning an application on an HCS12 protoboard, it uses a relatively 
small amount of code, but needs a 'significant' amount of nonvolatile 
storage for data. My HCS12 has nominally 64K of flash plus 1K of EEPROM. It 
appears that normally the flash is used for program storage, and the EEPROM 
for nonvolatile static data. 1K for data isn't near enough in my case, but 
the combined code and data will fit easily in the flash space.

For specific reasons, it isn't convenient to load data into the flash as one 
would a program. I want to do the flash load of the data under control of 
the in-module code (also running in flash), the data would come in through 
the serial port, with appropriate handshaking to allow for the write delays.

From what I can see, using flash memory in this way isn't a common or 
standard approach, or am I wrong? Is there any specific reason why it can't 
be made to work? TIA 

> From what I can see, using flash memory in this way isn't a common or 
> standard approach, or am I wrong?

You are wrong.

> Is there any specific reason why it can't be made to work? TIA

Nope.

Leo Havm�ller.

"Bruce Varley" <bv@NoSpam.com> wrote in message
news:vvudnQx-Cq9OAYzTnZ2dnUVZ8jednZ2d@westnet.com.au...
> Hi, I'm planning an application on an HCS12 protoboard, it uses a
relatively
> small amount of code, but needs a 'significant' amount of nonvolatile
> storage for data. My HCS12 has nominally 64K of flash plus 1K of EEPROM.
It
> appears that normally the flash is used for program storage, and the
EEPROM
> for nonvolatile static data. 1K for data isn't near enough in my case, but
> the combined code and data will fit easily in the flash space.
>
> For specific reasons, it isn't convenient to load data into the flash as
one
> would a program. I want to do the flash load of the data under control of
> the in-module code (also running in flash), the data would come in through
> the serial port, with appropriate handshaking to allow for the write
delays.

Hi Bruce,

It *can* work, but only if the flash is "self-programming", meaning that the
flash can be programmed by the software running from that same flash.
Sometimes this is only possible if the programming code runs from a
bootsector. If the program is larger than the bootsector, a workaround can
be to place the programming code only in the bootsector, which is then
called from the main application in de application area of the flash.

This should all be described in detail in the datasheet of the processor.

Meindert

In article <vvudnQx-Cq9OAYzTnZ2dnUVZ8jednZ2d@westnet.com.au>, 
bv@NoSpam.com says...
> 
> From what I can see, using flash memory in this way isn't a common or 
> standard approach, or am I wrong? Is there any specific reason why it can't 
> be made to work? TIA 

Check the hardware component selection, implementation and the data 
sheets for the parts. Some implementations do not allow for code fetch 
from a FLASH component while simultaneously trying to write or erase to 
other blocks. This could apply equally to FLASH parts mounted on an 
external memory interface or to on-board FLASH on an MCU. I have, in the 
past, had to provide for a small driver module that executed out of MCU 
RAM to be able to support in application write/erase of FLASH for some 
implementations. Other MCUs that I've worked with easily allow code 
execute from one area of FLASH while at the same time performing write 
or erase cycles to another region. 

-- 

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

On Mon, 4 Jul 2011 18:58:28 +0800, "Bruce Varley" <bv@NoSpam.com> wrote:

[snippety snip]

>From what I can see, using flash memory in this way isn't a common or 
>standard approach, or am I wrong? Is there any specific reason why it can't 
>be made to work? TIA 

It can be made to work but it is highly processor-specific. Some
families can do this but only if the executing code is in RAM, others
only if it's running out of a special "bootblock" area, many others
don't allow it at all. I'd guess that the latter case results from a
conflict with the 'normal' internal machine registers and control lines
and the logic used to erase and burn memory locations.

Also, look here
<http://forums.freescale.com/t5/16-Bit-Microcontrollers/Reprogramming-Erasing-flash-while-running-code-from-it-on-HCS12/td-p/12160>

-- 
Rich Webb     Norfolk, VA

Bruce Varley wrote:

> Hi, I'm planning an application on an HCS12 protoboard, it uses a relatively 
> small amount of code, but needs a 'significant' amount of nonvolatile 
> storage for data.

The HCS12 can program the internal flash by itself. The flash is 
conveniently divided into protected and unprotected sectors. The part of 
code which does the actual programming should be executed from a memory 
other then flash; i.e. from RAM or EEPROM.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jul 4, 7:27=A0pm, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl>
wrote:
> "Bruce Varley" <b...@NoSpam.com> wrote in message
>
> news:vvudnQx-Cq9OAYzTnZ2dnUVZ8jednZ2d@westnet.com.au...> Hi, I'm planning=
 an application on an HCS12 protoboard, it uses a
> relatively
> > small amount of code, but needs a 'significant' amount of nonvolatile
> > storage for data. My HCS12 has nominally 64K of flash plus 1K of EEPROM=
.
> It
> > appears that normally the flash is used for program storage, and the
> EEPROM
> > for nonvolatile static data. 1K for data isn't near enough in my case, =
but
> > the combined code and data will fit easily in the flash space.
>
> > For specific reasons, it isn't convenient to load data into the flash a=
s
> one
> > would a program. I want to do the flash load of the data under control =
of
> > the in-module code (also running in flash), the data would come in thro=
ugh
> > the serial port, with appropriate handshaking to allow for the write
>
> delays.
>
> Hi Bruce,
>
> It *can* work, but only if the flash is "self-programming", meaning that =
the
> flash can be programmed by the software running from that same flash.
> Sometimes this is only possible if the programming code runs from a
> bootsector. If the program is larger than the bootsector, a workaround ca=
n
> be to place the programming code only in the bootsector, which is then
> called from the main application in de application area of the flash.
>
> This should all be described in detail in the datasheet of the processor.
>
> Meindert


Yup, *delay* thats what gonna happen for sure. Didn't check the
specific mcu but your approach should work unless its something really
unique.  Generate data via code path as much as possible.

regards,
ali