Tips for QG8 flash EEPROM emulation

[SBLC]

Recently, I decide to use qg8 to replace silab's 8051 mcu. The first problem I meet is the EEPROM emulation . In the 8051, it simply use movx instruction to access the flash memory as EEPROM, but it seems difficult in HCS08 family.

I had go through many documents, most of them are not clearly told the detail information about using flash to emulate EEPROM. Finally I download the source code in c from this forum, the link is http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=8708&query.id=48016....

but unfortunelly, there is no document memtion about the details, so I want to share what I know about EEPROM emulation in QG8, maybe someone already know....

First, please download the QG8 flash 6.zip from the link, you can directly run this project without any modifications. but if you want to merge these code into your project, you must modify the .prm file.

In this section, (I assume the EEPROM locate in 0xe000 to 0xe1ff page)

SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
    Z_RAM                    =  READ_WRITE   0x0060 TO 0x00FF;
    RAM                      =  READ_WRITE   0x0100 TO 0x025F;
    ROM                      =  READ_ONLY    0xE000 TO 0xFFAD;
    ROM1                     =  READ_ONLY    0xFFC0 TO 0xFFCF;
 /* INTVECTS                 =  READ_ONLY    0xFFD0 TO 0xFFFF; Reserved for Interrupt Vectors */
END

a.) add this line
    EEPROM      = READ_ONLY 0xE000 to 0xE1FF   // reserve space to prevent overlap of code
b) modify
    ROM            = READ_ONLY 0xE200 to 0xFFAD    //
c) add
    CODE_RELOC   = READ_ONLY 0xE200 to 0xE240 RELOCATE_TO 0x0060

I'm not sure what the c). do, because the flash routines are not locate in 0xE200 to 0xE240 in my program, but it still can run.

Finally, if you want to "write" certain address, you must run the "CopyErase" first, the "CopyErase" routine will clear (or reset?) the content of the EEPROM to 0xff so that you can "write" this address again.

This is because the "write" process only set the required bits to "0", not "1". For example, if writing a value "0xa5" into address 0xE000, the process will be
1. call CopyErase
2. call CopyProgram
3. call RunProgram

then, if a new value of 0x5a should be update, the process is the same as above, if skip (1), the data in 0xE000 will be "0x00".

[Ake]

Hi,

I read your message with interest and finally I looked up the code that caused all those problems you were refeering to.

Ohoh!! It was my code!

Let me try to answer the questions you had:

a.) add this line
    EEPROM      = READ_ONLY 0xE000 to 0xE1FF   // reserve space to prevent overlap of code
b) modify
    ROM            = READ_ONLY 0xE200 to 0xFFAD    //
c) add
    CODE_RELOC   = READ_ONLY 0xE200 to 0xE240 RELOCATE_TO 0x0060
a) sets up the EEPROM segment. It should be at least 1 page long.

b) the ROM code should be modified to avoid collisions with the EEPROM buffer.

c) this is to tell the compiler that the code that is between 0xE200 - 0xE240 will be moved to address 0x60. So a label at eg 0xE245 should be moved to 0x65.

You write

"Finally, if you want to "write" certain address, you must run the "CopyErase" first, the "CopyErase" routine will clear (or reset?) the content of the EEPROM to 0xff so that you can "write" this address again.

This is because the "write" process only set the required bits to "0", not "1". For example, if writing a value "0xa5" into address 0xE000, the process will be
1. call CopyErase
2. call CopyProgram
3. call RunProgram"

CopyErase() copies part of itself down to address 0x60 and calls the entry address there.

It will then erase a bit of the Flash EPROM

CopyProgram() copies itself into 0x60. It doesn't do anything else.

The RunProgram() calls address 0x60.

The routine stored in this position, will take the R[] and program it into the Flash EPROM.

Your last questions was:
"Finally, if you want to "write" certain address, you must run the "CopyErase" first, the "CopyErase" routine will clear (or reset?) the content of the EEPROM to 0xff so that you can "write" this address again."

Answer: If you want to write a value to a Flash EPROM, it must contain 0xff. Everything else, it must be erased. And you cannot erase a single byte, so therefore to change a single byte, you must save a page of Flash EPROM, erase it, modify the byte in the RAM buffer and write everything back again.

I hope I have answered some of your questions.

If not please tell me!

Regards,

Ake

[SBLC]

Hi Ake,

Thank you for answering my question.

Concerning the question about the "CODE_REALCO", it's obviously that the flash routine didn't locate in the address between 0xe200 to 0xe240 (in the project.map file), and the size of "Erase" and "Program" are about 70 bytes, I don't know how it works.

According to the Codewarrior manual, the "RELOCATE_TO" keyword means that to reserve ram space to load the code from the range of the address, that is, 0xe200 to 0x240 relocated to 0x60 to 0x100. Actually, the flash "Erase" and "Program" routine didn't locate within these address, althought my code can run correctly,  I still confused about this setting.

Thank you again!

[Ake]

Hello,

I took a look in the Project.map file:

MODULE:                 -- main.c.o --
- PROCEDURES:
     EraseFlash                                E227      46      70       1   ROM        
     CopyErase                                 E26D      4D      77       1   ROM        
     InitFlash                                 E2BA       B      11       1   ROM        
     ProgFlash                                 E2C5      4B      75       1   ROM        
     CopyProgram                               E310      35      53       1   ROM        
     RunProgram                                E345       E      14       2   ROM        

and the EraseFlash routine was 70 bytes long and the ProgFlash was 75.

The space in the CODE_REALCO was 0xe240 - 0xe200 = 0x40 = 64 bytes.

It doesn't look good, but the reason why it works is that all of the labels inside the routines are within the first 64 bytes.

So the addresses were inside those 64 bytes, though the code did not fit.

But thanks for your observation, I will change the size of CODE_REALCO to 80 bytes.

Regards,

Ake

[SBLC]

Hi Ake,

In my opinion, the RELOC seems not very important, please take a look for the .map file in my project,

MODULE:                 -- flash.c.o --
- PROCEDURES:
     EraseFlash                                E5A3      46      70       1   ROM        
     CopyErase                                 E5E9      4D      77       2   ROM        
     InitFlash                                 E636       F      15       1   ROM        
     ProgFlash                                 E645      4B      75       1   ROM        
     CopyProgram                               E690      35      53       2   ROM        
     RunProgram                                E6C5       E      14       1   ROM        

I copy your code to a another file "flash.c"  (because there is  a main.c in my project),  the flash  routines are part of my code, and all of the "EraseFlash" and ProgFlash" routne 's address are outside 0xe200 to 0xe240, but I still can modify  the content in 0xe000 (I use only one byte) without error.

By the way, I lost one important step while using the flash routines---> before running these routines, the "DISABLEINTERRUPT" macro should use so that the flash routines can execute correctly, otherwise, the system might halt.

Besides, since the flash routines should be copy to the ram space to execute, the QG8 has only 512 bytes, it seems that it is impossible to use the full page as "EEPROM", right?

Regards,

Jason


Message Edited by SBLC on 2008-02-07 06:42 AM

[bigmac]

Hello Ake,

With the EEPROM emulation method under discussion, does this require that Z_RAM (160 bytes) is not available for any other purpose?  It would appear that the EraseFlash or ProgFlash routines may overwrite any variables allocated to Z_RAM.  Should the range of Z_RAM be reduced by 80 bytes, so there is no overlap in the allocations by the linker?

For devices such as the QG8, with very limited RAM resources, I think I prefer the alternative concept of using the stack to run the RAM based erase and program routines.

Regards,

Mac