CW Over-writing non-volatile data in FLASH

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

CW Over-writing non-volatile data in FLASH

跳至解决方案
1,571 次查看
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. */

标签 (1)
0 项奖励
回复
1 解答
527 次查看
Thunder
Contributor III
Thanks alot Rocco.  Works great.

在原帖中查看解决方案

0 项奖励
回复
4 回复数
528 次查看
Thunder
Contributor III
Thanks alot Rocco.  Works great.
0 项奖励
回复
527 次查看
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 项奖励
回复
527 次查看
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 项奖励
回复
527 次查看
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 项奖励
回复