Debugger wont initialise RAM, it thinks its flash!

[CarlFST60L]

Hi,

I have just ported my CW7.2 project to CW10.1 (52259demo board with MQX). 

I have a problem with the debugger not initializing a section that I have created within RAM, it seems to think its Flash, but its exactly the same as my CW7.2 project (it was MQX3.6 now also using MQX3.7). It looks like the debugger in CW10.1 is not able to realise that it can just write to address in RAM for section you create yourself? 

After pressing debug, it programs all the flash but comes up with a message box saying

"Download Task Failure

Error: 0x000002D8 of Target Memory at 0x2000C000 is not within flash boundaries.

do you want to continue?"

We have allocated a section in RAM at 0x2000C000, and the programmer (use to) program this section of RAM, then the code uses this as EEPROM copy space.

This all worked in CW7.2 with MQX3.6, now for some reason CW10.1 and MQX3.7 wont initializes the RAM for me in this way. Is there a way to force the debugger to know that RAM is RAM and not RAM is flash?

These are the two lines from my linker that allocate this memory in RAM:

NV_RAM         (RW): ORIGIN = 0x2000C000, LENGTH = 0x00000600  # SRAM - This the RAM copy of EEPROM

.NVM_Page:{nvm_c.c (.data)nvm_c.c (.rodata)nvm_c.c (.text)} > NV_RAM

The actual file nvm.c is setup like this

..

#pragma explicit_zero_data on

#pragma force_active on

volatile uchar NVM_BASE = 0;//Just one example of a variable

#pragma explicit_zero_data off

#pragma force_active off

...

[CarlFST60L]

BTW, I am using Multilink USB for Coldfire V2/3/4 on Win7.

I guess something in the tool chain is not parsing the S19 data and saying "if address in RAM range > write value directly"? Can this be fixed up? or is there a work around?

I do not want to relocate this to flash etc, its just to nasty, this is clean and easy.

[CrasyCat]

Hello

According to my understanding the message is generated when you are programming the flash.

If you intend to program the flash you need to generate a ROM image, which will generate the appropriate code to copy initialization data from ROM to RAM at startup.

Please check MCU_ColdFire_Compiler.pdf reference manual.

The chapter ELF Linker and Command Language section LCF Syntax > ROM-RAM Copying provides you with  a description and an example how to achieve that.

CrasyCat

[CarlFST60L]

I don't think I have explained myself well.

I guess my question is, how do I get CW10.1 to program the RAM with the data in my S19 instead of telling me "its not in flash space", I just want it to program the RAM and Flash like we have always done on previous Codewarrior versions. Flash programming is no problem, my linker is doing what I want and producing the correct S19 output with the data in the RAM locations I want, its just the debugger no longer initilises the RAM with the data from my S19.

Why we do this; we use this method as an easy way to program the peripheral memory devices on the very first boot (with debugger attached). Basically, the software boots from debug with the ram initialized by the debugger with the data from the S19, the software knows this based on the values in RAM, and copies the entire data table into our EEPROM + FLASH + Other peripherals then boots to normal code freeing up all the RAM and Flash that would be required by other methods. 

Thanks in advance,

Carl

[CarlFST60L]

I really need to get this resolved, I have service requests with both Freescale and Pemicro to try to get an answer.

I need to be clear as this is the response I seem to get from everyone:

***We cannot use the 'relocate ROM to RAM options', this has nothing to do with our application or problem, our problem is simply that RAM data in the S19 file is not programmed when you hit debug***

All we need to do is have the data in the S19 that is in RAM locations to be loaded into RAM locations as it use to do i.e. you hit debug, memory that is in Flash locations gets flashed, memory that is in RAM locations gets loaded into RAM, simple right? It use to work on my XP machine with CW7.2, the same code, same linker file does NOT do this in CW10.1. For some reason, something in the tool chain says "this is RAM, not Flash, so I am not going to program it". There is NO reason why the debugger should not be programming RAM values from the S19 file, after all, it has been working for years for us until CW10.1 and Win7 update. I have a large application that works and cannot be changed without months of work (program, the full test of software), and we have come to far with CW10 to go back to XP and CW7.2.