Changing memory location where CW flashes code

[gtorres88]

I'm working on implementing a bootloader on a MC9S12C128 and I want to place it in a different location that what codewarrior defaults to (which is 0xC000). Does anyone know how to tell CW 4.7 to instead flash starting at a different location (say 0xF000).

Thanks,

Gabe

[Jim_P]

actually you need more than just that.

the boot loader will use ram,  this should be keep separate from the application ram.

also any constants and strings need to have their defined area.

as an update of the code could change the amount of application ram and depending upon how the boot loader ram is assigned

a possible conflick can occur

Jim P

[kef]

Actually bootloader and application are two separate applications that may have allocated two different variables at the same address in RAM. This is OK, because either bootloader is running, or it jumps to start of application and application is running, not both at the same time. 

Building app+boot binary from the same project containing both boot and app code is IMO wrong and dangerous. It is hard if not impossible to separate boot and app resources, so that you can erase app only, not risking to erase parts of bootloader or shared runtime code. Also you are sticked to use this and only this specific compiler, because app and boot must have compatible compiler settings and the same version of runtime library. Anyway it is better to have independent application and bootloader, so that you can download code made using Cosmic or GNU C or other tools.

[Jim_P]

actually, I am doing just this

the boot loader is build in to a real time monitor that allows remote debugging and program checkout with a series of features over a serial port.  Later will be updated to USB for some upcoming project.

The monitor has a library of functions - - - kind of like standard bios functionality

complete with start up messages,  (hey have to know if the micro came up and started working - right)

monitor features include such items as application halt - - routine that breaks puts the application into safe mode.

Note micro can be controlling motors, -  so puts I/O into safe mode, and halts all application processes

(monitor command that calls application halt routine)  and also monitor has application start.

along with real time memory dump, while the application program is running.

and status messages being sent out.

Note this all interfaces with a Delphi PC program that displays the messages and provide control - -

and is expended for each project to have project interface screen that allows for changing settings. - -

displaying of parameters in the Micro - - timer values, micro temp, ADC readings, converted to human readings

(not simply a hex value or raw values but convered into - - - - if timer value relates to speed, it displays the related speed for the timer value,  if the ADC is measuring pressure, the application PC interface converts the reading to pressure, )

So this monitor gives a in depth view into what the micro is doing, in real time,  Limited only by buad rate in terms of what

can be passed back and forth.

This monitor also allows for updating the settings block in flash, and also erasing the flash and reprogramming.

The micro monitor knows the program area that is used by the monitor so will not allow erasing and reprogramming of that area.  Also the PC interface is provided with this information also - - - - upon micro power up.

[kef]

But that's not just the bootloader, which doesn't need any RAM reserved. Monitor service is always awake and may need some state variables allocated in RAM.

[Jim_P]

That is all true

but it sure makes a great debugging tool - - - - watch variables, decode and display status messages,

Hypertool type of logging window with control code translation,Scroll back

the ability to limit messages that are displayed - - -

and the ability to monitor memory locations (variables while the code is running at full speed)

makes a great debug tool - - takes about 1K of code space.

Buffered input and output - - largest amount of ram is used for the output buffer - - - -

along with a library of general functions, byte to hex, outchar, and many other low level routines

Jim P

[kef]

Edit your *.prm file, change highlighted figure

ROM_C000      = READ_ONLY     0xC000 TO   0xFEFF;

[gtorres88]

I will try this. Thank You.