Error verifying code at address

[Greeny]

Hi all,

i´m trying to program the M9S12C64 microcontroller with Codewarrior IDE 5.9.0.

i was creating a project with the wizard an have adapted the memory map in the .prm file to the following:

 NAMES
END

SEGMENTS                                                                        
    RAM = READ_WRITE 0x3000 TO 0x3FFF;

    /* unbanked FLASH ROM */
 
    ROM_7000 = READ_ONLY  0x4000 TO 0x7FFF;

  ROM_8000 = READ_ONLY  0x8000 TO 0xBFFF;  
    /* banked FLASH ROM */
   // PAGE_3C = READ_ONLY  0x3C8000 TO 0x3CBFFF;
                  
    ROM_C000 = READ_ONLY  0xC000 TO 0xF77F;
   
END

PLACEMENT
    _PRESTART, STARTUP,
    VIRTUAL_TABLE_SEGMENT,
    DEFAULT_ROM,
    OTHER_ROM                    INTO  ROM_7000,ROM_8000;
    NON_BANKED, COPY             INTO  ROM_C000;
               
    DEFAULT_RAM                  INTO  RAM;
END


STACKSIZE 0x0100

When i download the program i geht the error: 

Loading verification failed at address 0x0000FF80

Thats where my interrupt vectors are. What can i do to avoid this error ??

greetings

[J2MEJediMaster]

I've looked at the .prm files for similar MCUs, and they all end with the statement:

VECTOR ADDRESS 0xFFFE _Startup

which links the Startup routine to the reset vector address in the vector table.

Check some of the .prm files in the code examples folder that came with the CodeWarrior installation to see if this is the case.

---Tom

[CompilerGuru · Accepted solution]

That line is only added conditionally to new projects, its not added for example when targetting processor expert.

I think the original post does not contain enough information to diagose the issue yet.

I wounder therefore

- which version? (IDE 5.9 is the editor version...)

- which target connection?

- a log of the download?

- when disabling verify, how does the memory at 0xFF80 look like? What is different

- are the remaining parts of the app properly flashed?

As wild guess: the Serial monitor does vector redirection, so with the serial monitor something written to 0xFF80 ends up at the redirected vector location.

The probable best way to check this is to enable logging in the target connection.

Daniel