CW Over-writing non-volatile data in FLASH

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW Over-writing non-volatile data in FLASH

Jump to solution
1,386 Views
Thunder
Contributor III

Hi,  I am using the program doOnstack to use the stack for programming bytes to flash.  Everything is working OK.  I can open the CW memory window and see the data written, which remains after a power cycle/reset.  However, when I reflash the device, the non-volatile data is over-written with 1's.  My .prm file was modified to set aside 512b for the non-volatile area.  A copy of the .prm is shown below for reference.  The non-volatile area extends from 0x8000 to 0x81FF.  After reading some of the threads on the subject here, I have also added the line,

    NV_DATA                             INTO  ROM0;    /* Added for non-volatile memory storage */
from a previous post.   However, still no luck in retaining the data after a CodeWarrior reflash.  Is there a setting in CW to instruct the linker to avoid erasing the non-volatile area ?  Thanks.

 

NAMES END /* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your own files too. */

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 0x081F;
    ROM0                     =  READ_ONLY    0x8000 TO 0x81FF;       /* NV Data storage */
    ROM                      =  READ_ONLY    0x8200 TO 0xFFAD;       // originally 0x8000 to 0xFFAD
    ROM1                     =  READ_ONLY    0xFFC0 TO 0xFFC9;
 /* INTVECTS                 =  READ_ONLY    0xFFCA TO 0xFFFF; Reserved for Interrupt Vectors */
END

PLACEMENT /* Here all predefined and user segments are placed into the SEGMENTS defined above. */
    DEFAULT_RAM,                        /* non-zero page variables */
                                        INTO  RAM;

    _PRESTART,                          /* startup code */
    STARTUP,                            /* startup data structures */
    ROM_VAR,                            /* constant variables */
    STRINGS,                            /* string literals */
    VIRTUAL_TABLE_SEGMENT,              /* C++ virtual table segment */
    DEFAULT_ROM,
    COPY                                /* copy down information: how to initialize variables */
                                        INTO  ROM; /* ,ROM1: To use "ROM1" as well, pass the option -OnB=b to the compiler */

    _DATA_ZEROPAGE,                     /* zero page variables */
    MY_ZEROPAGE                         INTO  Z_RAM;
END

STACKSIZE 0xA0

VECTOR 0 _Startup /* Reset vector: this is the default entry point for an application. */

Labels (1)
0 Kudos
1 Solution
342 Views
Thunder
Contributor III
Thanks alot Rocco.  Works great.

View solution in original post

0 Kudos
4 Replies
343 Views
Thunder
Contributor III
Thanks alot Rocco.  Works great.
0 Kudos
342 Views
Thunder
Contributor III

answers to your questions...

By refreshing the device, I am reflashing from CW though the BDM.  I'm not using my own routine, just hitting the green arrow in the CW user interface to program.  I am using an HCS08LG32 for now, but may be migrating to another device (JM?) in the next iteration.  I am using the P&E multilink USB pod.  Hopefully, this doesn't lead me into the involved routine you are forced to use.  One would think there's a compiler command to set aside the non-volatile memory from erasure, but I'm just guessing here.    BTW. I'm using CW ver 6.2, which should be the latest rev.

0 Kudos
342 Views
rocco
Senior Contributor II

Hello again Thunder,

 

I believe you can do what you need with the multilink, although I have no way to test this. The multilink puts different menu items in the Hiwave debugger than the OSBDM does.

 

This thread talks about the problem, from the perspective of a couple of different MCUs (it seems each MCU/BDM interface combination is different):

 

http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&thread.id=5903

 

Hopefully, your answer is in there somewhere.

0 Kudos
342 Views
rocco
Senior Contributor II

Hi Thunder,

 

A few questions:

When you say "reflash the device", are you refering to reflashing from CW through the BDM? Or reflashing with your own programming routine?

 

What is the "device"?

 

What is your BDM interface? P&E? OSBDM?

 

I had this problem when reflashing through the BDM with the OSBDM. When the OSBDM reflashes the device, it erases the ENTIRE flash prior to programming. The P&E BDM interface allows you to set aside areas of flash to leave intact, but the OSBDM cannot do this.

 

For the OSBDM, you would need to shut off erasing altogether, and then erase manually. To shut of automatic erasing, you need to issue the command "flash aefskiperasing" on the hiwave command line. You then can go into the "flash" dialog box, and manually erase the portion of flash that you need to reprogram. However, depending on your "device", the only option may be to mass-erase the entire flash.

 

In my case, I needed to:

1) disable automatic erasing,

2) erase the flash, which was almost all of it (one small page was left intact, but was too small for me to use).

3) reprogram the "data" portion of flash (which is DSP code).

4) reflash the program code.

 

Yes, very tedious, very awkward. But at least it works . . . Which I no longer take for granted.

0 Kudos