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. */
已解决! 转到解答。
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.
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.
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.