Sign in

username:

password:



Not a member?

Search 68hc12



Search tips

Subscribe to 68hc12



68hc12 by Keywords

68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Ads

Discussion Groups

Discussion Groups | 68HC12 | MC9S12A64 Memory Mishap

Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).

MC9S12A64 Memory Mishap - Author Unknown - Mar 13 20:49:00 2005

I've got a strange problem that I would really appreciate some help with.

I've been developing code for an MC9S12A64 product, and I've been flashing
and debugging using a PEMicro BDM-Multilink cable, as well as an older
Cable12 cable. I'd encountered no problems with flashing and debugging using
an IAR Embedded Workbench IDE and BDM for nearly a full year of work.

Recently my project seemed to be approaching the limits of the flash memory,
and the linker started complaining that I had exceeded the amount of
available flash. Here's what my .map file looked like just before my project
started exceeding the flash limit:

SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE
ALIGN
======= ===== ============= =========== ==== ====
=====
DATA1 1000 dse
0
IDATA1 1000 - 126B 26C rel
0
UDATA1 126C - 1A72 807 rel
0
TEMP 1A73 dse
0
WCSTR 1A73 dse
0
ECSTR 1A73 rel
0
CSTACK 1A73 - 1E72 400 rel
0
NO_INIT 2000 - 2132 133 rel
0
CDATA0 4000 rel
0
CCSTR 4000 rel
0
CDATA1 4000 - 426B 26C rel
0
<CONST,CSTR,RCODE> 1
426C - 7FFD 3D92 rel
0
<CONST,CSTR,RCODE> 2
C000 - D6CB 16CC rel
0
INTVEC FF80 - FFFF 80 com
0
<CODE> 1 003C8000 - 003CBFFC 3FFD rel
0
<CODE> 2 003D8000 - 003DBF82 3F83 rel
0
UDATA0 FFFFFFFF rel
0
DATA0 FFFFFFFF dse
0
IDATA0 FFFFFFFF rel
0 The four flash segments I've shown in color above. The segment shown in red,
I noted, was not very full. I checked my linker file and found the
following:

-Z(CODE)CCSTR,CDATA0,CDATA1=4000-7FFF,8000-BFFF,C000-FF7F
-P(CODE)RCODE,CONST,CSTR,CHECKSUM=4000-7FFF,C000-FF7F
-P(CODE)CODE=[3C8000-3CBFFF]*2+10000

The CODE segment, I noted, went from 3C8000 to 3CBFFF (banked memory). So,
in order to allow the linker to also place code between C000 to D6CB, I
changed the linker file as follows:

-Z(CODE)CCSTR,CDATA0,CDATA1=4000-7FFF,8000-BFFF,C000-FF7F
-P(CODE)RCODE,CONST,CSTR,CHECKSUM=4000-7FFF,C000-FF7F
-P(CODE)CODE=C000-FF7F,[3C8000-3CBFFF]*2+10000

This appeared to work. My larger program built and linked successfully. The
new .map file looked as follows:

SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE
ALIGN
======= ===== ============= =========== ==== ====
=====
DATA1 1000 dse
0
IDATA1 1000 - 126B 26C rel
0
UDATA1 126C - 1A72 807 rel
0
TEMP 1A73 dse
0
WCSTR 1A73 dse
0
ECSTR 1A73 rel
0
CSTACK 1A73 - 1E72 400 rel
0
NO_INIT 2000 - 2132 133 rel
0
CDATA0 4000 rel
0
CCSTR 4000 rel
0
CDATA1 4000 - 426B 26C rel
0
<CONST,CSTR,RCODE> 1
426C - 7FFD 3D92 rel
0
<CODE,CONST,CSTR,RCODE> 1
C000 - FF7E 3F7F rel
0
INTVEC FF80 - FFFF 80 com
0
<CODE> 1 003C8000 - 003CBFFD 3FFE rel
0
<CODE> 2 003D8000 - 003D97CA 17CB rel
0
UDATA0 FFFFFFFF rel
0
DATA0 FFFFFFFF dse
0
IDATA0 FFFFFFFF rel
0 I was also able to flash the new program into my target processor, and it
seems to run correctly.

Here's the problem:

I am no longer able to flash my target boards. When the first one stopped
working, I tried flashing the code into the second board, and it immediately
suffered the same fate. Now I have two target boards which are permanently
flashed with that version of software. I can no longer use BDM to flash
them.

Symptoms:
If I use P&E's PROGG12Z programmer (instead of the IAR IDE) the programmer
finds the BDM cable, but it is unable to communicate with the target
processor. IAR IDE complains that it cannot determine the correct frequency
to use with the target processor, but I believe that error message is just a
general "doesn't work" message that the IDE displays whenever it can't
successfully communicate with the target processor... such as when no power
is applied to it.

It appears as if my memory changes allowed the linker to violate some
Motorola flash memory constraint, overwriting some critical part of flash.
Is that possible? I haven't found any such constraints documented in
Motorola literature.

Does anyone have any ideas what happened?
[Non-text portions of this message have been removed]


Re: MC9S12A64 Memory Mishap


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )


Re: MC9S12A64 Memory Mishap - zeta_alpha2002 - Mar 13 21:14:00 2005


> Does anyone have any ideas what happened?

It appears that you accidentally secured the MCU. I think PEMicro has
an usecure utility. --- In , <cscharlau@e...> wrote:
> I've got a strange problem that I would really appreciate some help
with.
>
> I've been developing code for an MC9S12A64 product, and I've been
flashing
> and debugging using a PEMicro BDM-Multilink cable, as well as an older
> Cable12 cable. I'd encountered no problems with flashing and
debugging using
> an IAR Embedded Workbench IDE and BDM for nearly a full year of work.
>
> Recently my project seemed to be approaching the limits of the flash
memory,
> and the linker started complaining that I had exceeded the amount of
> available flash. Here's what my .map file looked like just before my
project
> started exceeding the flash limit:
>
> SEGMENT SPACE START ADDRESS END ADDRESS SIZE
TYPE
> ALIGN
> ======= ===== ============= =========== ====
====
> =====
> DATA1 1000
dse
> 0
> IDATA1 1000 - 126B 26C
rel
> 0
> UDATA1 126C - 1A72 807
rel
> 0
> TEMP 1A73
dse
> 0
> WCSTR 1A73
dse
> 0
> ECSTR 1A73
rel
> 0
> CSTACK 1A73 - 1E72 400
rel
> 0
> NO_INIT 2000 - 2132 133
rel
> 0
> CDATA0 4000
rel
> 0
> CCSTR 4000
rel
> 0
> CDATA1 4000 - 426B 26C
rel
> 0
> <CONST,CSTR,RCODE> 1
> 426C - 7FFD 3D92
rel
> 0
> <CONST,CSTR,RCODE> 2
> C000 - D6CB 16CC
rel
> 0
> INTVEC FF80 - FFFF 80
com
> 0
> <CODE> 1 003C8000 - 003CBFFC 3FFD
rel
> 0
> <CODE> 2 003D8000 - 003DBF82 3F83
rel
> 0
> UDATA0 FFFFFFFF
rel
> 0
> DATA0 FFFFFFFF
dse
> 0
> IDATA0 FFFFFFFF
rel
> 0 > The four flash segments I've shown in color above. The segment shown
in red,
> I noted, was not very full. I checked my linker file and found the
> following:
>
> -Z(CODE)CCSTR,CDATA0,CDATA1=4000-7FFF,8000-BFFF,C000-FF7F
> -P(CODE)RCODE,CONST,CSTR,CHECKSUM=4000-7FFF,C000-FF7F
> -P(CODE)CODE=[3C8000-3CBFFF]*2+10000
>
> The CODE segment, I noted, went from 3C8000 to 3CBFFF (banked
memory). So,
> in order to allow the linker to also place code between C000 to D6CB, I
> changed the linker file as follows:
>
> -Z(CODE)CCSTR,CDATA0,CDATA1=4000-7FFF,8000-BFFF,C000-FF7F
> -P(CODE)RCODE,CONST,CSTR,CHECKSUM=4000-7FFF,C000-FF7F
> -P(CODE)CODE=C000-FF7F,[3C8000-3CBFFF]*2+10000
>
> This appeared to work. My larger program built and linked
successfully. The
> new .map file looked as follows:
>
> SEGMENT SPACE START ADDRESS END ADDRESS SIZE
TYPE
> ALIGN
> ======= ===== ============= =========== ====
====
> =====
> DATA1 1000
dse
> 0
> IDATA1 1000 - 126B 26C
rel
> 0
> UDATA1 126C - 1A72 807
rel
> 0
> TEMP 1A73
dse
> 0
> WCSTR 1A73
dse
> 0
> ECSTR 1A73
rel
> 0
> CSTACK 1A73 - 1E72 400
rel
> 0
> NO_INIT 2000 - 2132 133
rel
> 0
> CDATA0 4000
rel
> 0
> CCSTR 4000
rel
> 0
> CDATA1 4000 - 426B 26C
rel
> 0
> <CONST,CSTR,RCODE> 1
> 426C - 7FFD 3D92
rel
> 0
> <CODE,CONST,CSTR,RCODE> 1
> C000 - FF7E 3F7F
rel
> 0
> INTVEC FF80 - FFFF 80
com
> 0
> <CODE> 1 003C8000 - 003CBFFD 3FFE
rel
> 0
> <CODE> 2 003D8000 - 003D97CA 17CB
rel
> 0
> UDATA0 FFFFFFFF
rel
> 0
> DATA0 FFFFFFFF
dse
> 0
> IDATA0 FFFFFFFF
rel
> 0 > I was also able to flash the new program into my target processor,
and it
> seems to run correctly.
>
> Here's the problem:
>
> I am no longer able to flash my target boards. When the first one
stopped
> working, I tried flashing the code into the second board, and it
immediately
> suffered the same fate. Now I have two target boards which are
permanently
> flashed with that version of software. I can no longer use BDM to flash
> them.
>
> Symptoms:
> If I use P&E's PROGG12Z programmer (instead of the IAR IDE) the
programmer
> finds the BDM cable, but it is unable to communicate with the target
> processor. IAR IDE complains that it cannot determine the correct
frequency
> to use with the target processor, but I believe that error message
is just a
> general "doesn't work" message that the IDE displays whenever it can't
> successfully communicate with the target processor... such as when
no power
> is applied to it.
>
> It appears as if my memory changes allowed the linker to violate some
> Motorola flash memory constraint, overwriting some critical part of
flash.
> Is that possible? I haven't found any such constraints documented in
> Motorola literature.
>
> Does anyone have any ideas what happened? >
> [Non-text portions of this message have been removed]





(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: MC9S12A64 Memory Mishap - Author Unknown - Mar 14 7:38:00 2005

Date: Mon, 14 Mar 2005 01:14:13 -0000
From: "zeta_alpha2002" <>
Subject: Re: MC9S12A64 Memory Mishap

> Does anyone have any ideas what happened?

It appears that you accidentally secured the MCU. I think PEMicro has
an usecure utility.

========

PEMicro does indeed have an unsecure utility. I downloaded it, ran it, and
problem solved. Thank you very much!

Now to figure out how I managed to accidentally secure the processors.

BTW: This list has been a terrific resource the two times I have really
needed 68HC12 help.




(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: MC9S12A64 Memory Mishap - zeta_alpha2002 - Mar 14 10:41:00 2005


> Now to figure out how I managed to accidentally secure the >processors.

You code is too large now. You should exclude secure memory area from
code use or let the compiler know not to include the secure memory
area until you want security enabled.

--- In , <cscharlau@e...> wrote:
> Date: Mon, 14 Mar 2005 01:14:13 -0000
> From: "zeta_alpha2002" <zeta_alpha2002@y...>
> Subject: Re: MC9S12A64 Memory Mishap
>
> > Does anyone have any ideas what happened?
>
> It appears that you accidentally secured the MCU. I think PEMicro has
> an usecure utility.
>
> ========
>
> PEMicro does indeed have an unsecure utility. I downloaded it, ran
it, and
> problem solved. Thank you very much!
>
> Now to figure out how I managed to accidentally secure the processors.
>
> BTW: This list has been a terrific resource the two times I have really
> needed 68HC12 help.





(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )