Eeprom emulation on QG8 fails

[fjrg76]

Hi!! I've trying to emulate eeprom on QG8 derivative using the project NVM.mcp that I found in this forum (although I don't remember exactly where I get it, but that is not the problem right now), however when loading the code onto the chip through the P&E true-time emulator tool, the non-volatile register NVPROT (0xFFBD)  is written with 0x7E which blocks the entired flash so I'm not allowed to write in any flash location.

Inside that such a tool there is an "expert mode programmer" which allows me to write the value 0x01 (no flash protected) into 0xFFBD.  I decided to use the very first flash page as eeprom (starting at 0xE000), and for debugging process I disabled the flash protection. When ready I'll back to protect the rest of the flash.

However when loading my code onto the chip the location 0xFFBD is written with 0x7E, so I cannot write in flash.

Does anyone has been faced with the same problem?? Is there some way to tell the P&E true-time emulator tool not to write in such location?? Do I need to edit some config file??

I started a project  (PCB boards already made) thinking that emulation was an easy thing, so it's not posible to use an external eeprom chip, and now I know emulation is not as easy as expected, perhaps I'm missing something

Thanks to all and I'll waiting for your kindly answers. Regards =)

[fjrg76]

Thanks to everyone!!

Ake, the code you kindly provide us works well, and I'll modify it to my needs.

Peg, I had a mistake. The code I was using is not mine, it is from the appnote AN3404, and let me say it, it's plenty of errors. I haven't seen that somewhere in the code the location 0xFFBD has the value 0x7E, that's way it was always written with such value despite my wishes. However, after fixing it the code never works. When debugging step-by-step it works pretty well, but when let it running free, programm crashes. I was desesperate and getting mad because my boards are coming on monday, so there is no chance to add some external eeprom, but with the code posted by ake things seems gone right.

By the way, I found, for other of my projects, a SPI eeprom line with large capacities and not expensive: M25Pxx that ranges from  (64KBx8) to (16Mx8)

Thanks again for your time and patience. Regards =)

[fjrg76]

Hi bigmac!!

In fact I'm using real hardware, the DEMO9S08QG8 demonstration board from Axiom. Also I created the project with the "project wizard". Let me explain my self clearer step by step:

1. Inside the P&E emulation tool there is an option "start expert mode programmer" which let you do some tasks, like erase, load, etc, and among those tasks there is one "byte programm" that lets you to programm any byte in the flash. Well, with that option I clear the entire flash and then I only program the value 0x01 into the flash location 0xFFBD. Just that and everything is ok.

2. Inside the CodeWarrior editor I press F5, you know, compile and load. The P&E emulation tool becomes active and then it asks you to take some actions. I choose "Connect" and the code is loaded into the chip. And guess what?? The location 0xFFBD now has the value 0x7E !!!! I don't even need to run my code, immediatly after loading, that location takes its new value.

3. I've looked into the many files that belongs to the project but none of them has anything related to flash protection.

4. Also looking at the startup code nothing seems to be related with the flash protection. I have doubts about that because the new value for the NVPROT non-volatile register is changed before I run my code.

Someone kindly suggested my to code it in asm, but, as I said, perhaps my missunderstanding is not in the code but in the tool.

Some sugestions?? what am I missing when loading the code??

[peg]

Hi fjrg76,

The P&E programming component DOES NOT especially modify the NVPROT register!

It does however modify NVOPT to unsecure it after a mass erase and to set security via the SD command.
It also will write a value it determines into the TRIM and FTRIM if you ask it to.

But that is the extent of anything that happens automatically/behind your back.

All other flash locations are programmed purely based on the object file passed to the programmer.
If you find NVPROT at a value other than the erased state of $FF then the file you passed to the programmer told the programmer to do it.

Post a copy of the s19 file of your code and I will point it out to you.

[fjrg76]

Hi!!

I'll try it as soon as posible, but before that let me ask you whether should I edit some config file (or it was edit by you in your project), because, as said before, the P&E debugger writes 0x7E into the NVPROT register @ 0xFFBD  whenever loading the code, no matter what was there before then protecting the entire flash.

Thanks and I'll check it =)

[Sandeepsharma]

Hi,

  I am very new for EEPROM emulation, i tried the QG8 Flash 6.zip code as it is. it update the E000 memory locations, but if i try to do with single step or step over in debugger, it shows only 0x01 to 0x09 from E000 to E009 and updates happened. I have tried the steps used in the linked discussion.

Pls suggest me:

1)  I want to use this code in my program, what step i need to take.

2) I want to use EEPROM status update in keyboard intruppt, is it possible, if where i can update my intrupts variable in to EEPROM.

3) What is the procedue to retrive the data(can i use the same variable name.

4) during debugging R.Counter value become 0xE3 automatically after copyProgram function.

If you have any program, where this code is in use will be very helpful for me.

Message Edited by Sandeepsharma on 2008-05-22 03:32 PM

[bigmac]

Hello,

Are you actually testing your code using the real hardware, or are you attempting to use full chip simulation?  Your initial post is a little ambiguous on this point.  If using the latter, the full chip simulator does not attempt to simulate the programming of flash from within your code.  You will need to test your code using real hardware.

Since the erased state of the flash register NVPROT is 0xFF, I would expect this value to be present unless another value were specifically written (during the programming of your code to flash).  The default value would result in all flash memory being unprotected.

I suspect that there may be some misunderstanding of value required for the NVPROT register.  To leave the first flash page unprotected, but all other flash protected, I believe the register value should be 0xE0, i.e. the highest unprotected flash address would be 0xE1FF.

Regards,

Mac

Message Edited by bigmac on 2008-01-11 01:18 PM

[Ake]

Hi,

Here is a bit of code that demonstrates how to use the Flash EPROM as an EEPROM on the 9S08QG8..

(I believe it works).

Regards,

Ake

QG8_Flash_6.zip 

Message Edited by t.dowe on 2009-10-27 12:57 PM

[SBLC]

Hi Ake,

I download the attached file and successfully run with my demo9s08qg8 board. But while I ported into my project, it cannot work.

I had modify the project.prm contents,
**********************************************************************************************************
SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
    EEPROM                   =  READ_ONLY    0xE000 TO 0xE1FF;
    Z_RAM                    =  READ_WRITE   0x0060 TO 0x00FF;
    RAM                      =  READ_WRITE   0x0100 TO 0x025F;
    ROM                      =  READ_ONLY    0xE200 TO 0xFFAD;
    ROM1                     =  READ_ONLY    0xFFC0 TO 0xFFCF;
    CODE_RELOC               =  READ_ONLY    0xe200 TO 0xe240 RELOCATE_TO 0x0060;
   
 /* INTVECTS                 =  READ_ONLY    0xFFD0 TO 0xFFFF; Reserved for Interrupt Vectors */
END
*********************************************************************************************************
while my program run to "CopyErase" function, the debugger halt. I also view the project.map file,  I find
the "flash" related function didn't allocate into correct address,
**************************************************************************************
MODULE:                 -- flash.c.o --
- PROCEDURES:
     EraseFlash                                E5B0      46      70       1   ROM        
     CopyErase                                 E5F6      4D      77       1   ROM        
     InitFlash                                 E643       F      15       1   ROM        
     ProgFlash                                 E652      4B      75       1   ROM        
     CopyProgram                               E69D      35      53       1   ROM        
     RunProgram                                E6D2       E      14       1   ROM        
     GetMode                                   E6E0       4       4       1   ROM        
     SetMode                                   E6E4      1B      27       2   ROM        
- VARIABLES:
     rStoredValue                               103       1       1       1   .bss       
     StoredValue                               E000       1       1       2   .abs_section_e000
     FlashRamBuffer                             11E      50      80       6   .common    
******************************************************************************************

anyone can help me?





Message Edited by SBLC on 2008-02-02 01:56 PM

[CompilerGuru]

What did you change in the prm file?

The CODE_RELOC segment in the prm is not actually used. There appear to be some non completed adaptations in the prm to use the RELOCATE_TO feature of the linker.
But I guess the original content of the functions copied to RAM in main.c did just work fine without
that relocation, there are some code patterns which are not PIC (position independent code), but often small function are just PIC. So if there are just as simple things
to be executed in RAM, then it maybe just simpler (simple is good!) not to use the RELOCATE_TO, on the other side, using the RELOCATE_TO would help
in the most general case and especially when the functions to be executed in RAM would become larger (which they should not, of course).

So just conceptually what is missing in the RELOCATE_TO adaptations:
(Note: just out of my memory, I'm not having that chip or even CW 6.1 here).

To use it:
1. assign the content of a section into it in the prm.
>PLACEMENT
>   CODE_RELOC_ERASE_FLASH        INTO  CODE_RELOC;
>...
2. allocate the function in that section

#pragma push
#pragma CODE_SEG CODE_RELOC_ERASE_FLASH
unsigned char EraseFlash(unsigned char * far ptr) {
....
#pragma pop

An additional note, it may make sense to use a separate section and segment for all the functions to be copied. While this is inconvenient to have to specify the function sizes,
it helps that all the functions can be relocated to the same address.

But as I said, probably just keeping the original version not using the CODE_RELOC is probably the way to keep it simple.
So I would delete the CODE_RELOC and re-add its memories
(ram and flash) back to the other segments.

Daniel

[JimDon]

Well I don't know how this all got so complex, but for the record this is what works for me.
I got it from from some example some where, and it works fine tested on a QG4.
And, I'll tell you what - it erase and burns fine in the debugger, with a memory window open every time.

Here is one catch - if you don't go into "Debugging Memory Map"", edit the block where your flash is, and check "refresh memory when halting" you will THINK is not working because if you don't check that, True-Time will NOT show you the current state of that piece of memory.
If you don't normally have interrupts enabled, you may wish to change the SEI/CLI part. But DO NOT call erase with ints on, cause if you get an int the code will got to la-la land.

If you want to keep config data over burns, exclude your region from the prm file. When you use "Expert Mode Programmer", the config data will not get over written. However it appears that "Non-Volatile Memory Preservation" in the Advanced Options does not work (this could just be for Special Edition". Perhap an FSLer can confirm/deny this.) If you want it always reset. then leave the prm alone.

If it all needs to be more complex than this, please tell me, as I am currently under the delusion that this works. Feel free to wake me.

(This is just so you can see the return value while debugging)

volatile unsigned char temp;

Code:

#pragma MESSAGE DISABLE C1805
const unsigned char NVPROT_INIT @0x0000FFBD = 0xFF; // need this some where in your code.
const unsigned char NVOPT_INIT @0x0000FFBF = 0x7E;
#define Page_Erase   PGM[21]=0x40; temp = ((unsigned char(*)(unsigned int, unsigned char))(PGM))#define Program_Byte PGM[21]=0x20; temp = ((unsigned char(*)(unsigned int, unsigned char))(PGM))//Array of opcode instructions of the Erase/Program function in the HCS08 familyvolatile unsigned char PGM[59]  = {  0x87,0xC6,0x18,0x25,0xA5,0x10,0x27,0x08,0xC6,0x18,0x25,0xAA,0x10,0xC7,0x18,0x25,0x9E,0xE6,0x01,0xF7,0xA6,0x20,0xC7,0x18,0x26,0x45,0x18,0x25,0xF6,0xAA,0x80,0xF7,0x9D,0x9D,0x9D,0x9D,0x45,0x18,0x25,0xF6,0xF7,0xF6,0xA5,0x30,0x27,0x04,0xA6,0xFF,0x20,0x07,0xC6,0x18,0x25,0xA5,0x40,0x27,0xF9,0x8A,0x81}; void FlashErasePage(word page) {   volatile unsigned char temp ;   asm SEI;                             // Disable ints.   temp = Page_Erase(page,0);   asm CLI;                             // Enable interrupts     return;    }void FlashProgramByte(word address, byte data) {  volatile unsigned char temp;   temp = Program_Byte(address, data);   return;  }/*  The opcodes above represents this set of instructions      if (FSTAT&0x10){                     //Check to see if FACCERR is set        FSTAT = FSTAT | 0x10;            //write a 1 to FACCERR to clear    }    (*((volatile unsigned char *)(Address))) = data;  //write to somewhere in flash    FCMD = cmd;  // note we set this in the array to be the right command.        FSTAT = FSTAT | 0x80;                //Put FCBEF at 1.    _asm NOP;                            //Wait 4 cycles    _asm NOP;    _asm NOP;    _asm NOP;    if (FSTAT&0x30){                     //check to see if FACCERR or FVIOL are set    return 0xFF;                         //if so, error.    }    while ((FSTAT&0x40)==0){             //else wait for command to complete        ;    }*/

 

Message Edited by JimDon on 2008-02-02 08:18 PM

[tonyp]

I'm not well acquainted with the Codewarrior environment or the specific project you mention but there should be a setting somewhere in the configuration, or some definition as part of the default startup code.

One general 'trick' you can do to find such hidden code/definitions is code/define a different value for that location very early in your code (before any #include in your primary file) and hope the assembler/compiler compains with a warning/error when it hits that other 'hidden' definition you can't immediately see.

As a general work-around, if all else fails, you can always edit (out) the unwanted value from the produced S19 file before loading it into your device.

Using Flash as EEPROM is a piece of cake, your problem is more related to understanding better how your specific tool works.  (I use a plain assembler, and have no such problems.)

Message Edited by tonyp on 2008-01-09 11:12 AM