HCS12 Bootloader problem

I'm working with MC9S12A256B and CW 3.1, and I'm using bootloader from AN3275

The problem is that when I bootload my app (send .s19 via HyperTerminal) the reset vector is erased, inside address 0xFFFE I see 0x0000. So neither the bootloader nor the app runs, unless I manually set the PC = 0xF0C0 (Bootloader reset vector address). The strange thing is that all the other vectors (PLL, TIMER. COP, etc) are correct.

I try with a smallest app, wich doesn't use EEPROM variables and it worked fine, so I guess the problem is somewhere there. I've notice that when I've got a constant variable inside EEPROM page the bootloading process erase the reset vector.

I've define EEPROM segment as shown and then place variables using #pragma CONST_SEG EEPROM_DATA_PAGE .

SEGMENTS PAGE_EEPROM = READ_ONLY 0x0400 TO 0x0FFF;END

PLACEMENT EEPROM_DATA_PAGE INTO PAGE_EEPROM;END

The ONLY diference with the working app and the one that doesn't worksis that one puts variables inside EEPROM_DATA_PAGE and the other does not.

What could possibly be happening?

Thanks in advance!

PS: If you need the .s19 file or the complete .prm file ask, and I'll post it

Do you think is a problem related to CodeWarrior? I don't know much, but I don't think that's the problem. Please excuse me if I question what you suggest, it's because my lack of knowledge.

Loading both apps with HiWave works fine, the problem is when I try to load them sending the .s19 to the bootloader, via RS232.

I was thinking that it could be some "error" on the .prm files or something like that. Or may be I should change something in the bootloader.

I'll try to make it more detailed:

I've got the 3 apps:

1- Bootloader (the untouch code from AN3275)

2- My App without EEPROM variables @0x0400 (the "working" version)

3- My App with EEPROM variables @0x0400 (the "not working" version)

If I load any of those 3 apps with HiWave, each app works great.

Now, I only load the bootloader with HiWave. Enter bootloading mode, send the "working" version .s19 via RS232. It works great! Reset vector points to the bootloader, and there, it decides to execute the bootloader or jump to my app.

But, if I enter bootloading mode and send the "not working" version .s19 via RS232, it wouldn't work beacuse reset vector points to nothing (0x0000) If, when debbuging, I manually set the Program Counter to the Bootloader address (the value that should be at the reset vector) it works fine, and as before, the bootloader decide what to execute.

Three things to take note:

+ When reset vector points to nothing, all the others vector points to where they should. I found that strange beacuse, if there were some memory overlapping, the others vector wouldn't be pointing to their respective routines.

+ I needed to compile the bootloader using CW v4.6 because inside its .prm file, it set a segment as READ_WRITE and loads code there (the one to be executeted in RAM), and CW 3.1 don't allow a READ_WRITE attribute for a CODE_SEGMENT.

+ Why when a variable is defined in 0x0400 (EEPROM) the bootloader erase the reset vector? Because that seems to be the problem. I'll attach the AN3275 bootloader code.

I opened AN3275 pdf and found that EEPROM is expected to be at 0x2000! You have it 0x400. Also, since there's dedicated EEPROM menu, I'm not sure if this bootloader is able to program common flash+EEPROM S19 file, but I didn't read whole AN, maybe it's possible.

And then when I want to access that variable, just do a cast like this:

EEPROM_ptr = (byte*) EEPROM_MSJ_PREGRABADO_address;

I've done this in previous projects, before I learn how to use #pragmas and how to define segments in .prm file.

Besides, if I do it like I used to, I need to keep track of addresses, sizes, and alignment. Be defining a variable, and having always sizes that have modulo 4 equal 0 (%4 =0) the problem solves it self.

In case you don't specify initializer for object allocated in READ_ONLY segment, object is initialized with zeros and S19 file includes S-record(s) for EEPROM data. NO_INIT makes object not initialized.

I didn't know about it, everytime I worked with EEPROM I've never used NO_INIT, so all variables were initialized to 0x00, and I've to declare them (manually) as 0xFF so EEPROM always begin erased. Now I don't need to do that any more.