CodeWarrior for MCUのトピックRe: Error verifying code at address

Error verifying code at address

Greeny — Thu, 30 Apr 2009 18:46:19 GMT

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

Re: Error verifying code at address

J2MEJediMaster — Mon, 04 May 2009 22:43:49 GMT

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

Re: Error verifying code at address

CompilerGuru — Mon, 04 May 2009 23:29:53 GMT

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