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

Reply to
Bruce Varley
Loading thread data ...

You are wrong.

Nope.

Leo Havmøller.

Reply to
Leo Havmøller

relatively

It

EEPROM

one

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

Reply to
Meindert Sprang

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
 Click to see the full signature
Reply to
Michael Karas
[snippety snip]

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

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

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

formatting link

Reply to
Vladimir Vassilevsky

an application on an HCS12 protoboard, it uses a

.

but

s

of

ugh

the

n

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

Reply to
Ali

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.