EmbeddedRelated.com
Forums

MC9S12DP256 unlocking problems

Started by markstaples999 October 11, 2004

Hello all,

I am running in secure mode, however I need to write some parameters
off to the EEPROM so that they aren't lost when the power goes off.
So I want to unlock the chip, save the parameter, and then lock it up
again.

I am having problems with the unlocking side of things at the moment.
As far as I understand I cannot unlock executing code in ROM, so I
need copy the code into RAM and then execute it from there. This,
however is causing me a fair few headaches in codewarrior.

If anyone has an alternate method for saving variables into the
EEPROM, or has done this before I would appreciate some help with the
issue.
Currently to copy the ROM code into RAM I am
using the following code: void (*p1)(void);
void (*p2)(void);

*p1 = CodeInROM;
p2 = (void *)0x3F00;

memcpy(p2, p1, 64); __asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
thanks

Mark



Hello Mark.

Maybe off subject, but if the chip is locked, I guess you mean
"BDM-locked". I don't think that there is any limitation to write in eeprom
or flash from the running (standalone) application, even if the chip is
BDM-locked.
I guess only eeprom and flash protection should be handled.
Also I think a flash application can program in eeprom without any
restriction, even "flash to flash", if the destination is not in the same
block as the programming application.

Regards,
Gilles At 07:45 AM 10/11/2004, you wrote: >Hello all,
>
>I am running in secure mode, however I need to write some parameters
>off to the EEPROM so that they aren't lost when the power goes off.
>So I want to unlock the chip, save the parameter, and then lock it up
>again.
>
>I am having problems with the unlocking side of things at the moment.
>As far as I understand I cannot unlock executing code in ROM, so I
>need copy the code into RAM and then execute it from there. This,
>however is causing me a fair few headaches in codewarrior.
>
>If anyone has an alternate method for saving variables into the
>EEPROM, or has done this before I would appreciate some help with the
>issue. >
>Currently to copy the ROM code into RAM I am
>using the following code: >void (*p1)(void);
>void (*p2)(void);
>
>*p1 = CodeInROM;
>p2 = (void *)0x3F00;
>
>memcpy(p2, p1, 64); >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM >
>thanks
>
>Mark >
>Yahoo! Groups Links





Mark,

I believe there are two mechanisms in the HCS12 - Security, and Protection.

Secured mode prevents external BDM or hardware from reading the content of
your Flash and EEPROM.

In addition, sections in the Flash and EEPROM can be protected against
erase, and reprogramming, using the Protection mechanism.

The two mechanisms are separate as far as I know. Thus, if you run in
Secured mode, with the relevant EEPROM locations not protected (but still
secured), you should be able to erase these EEPROM locations, and reprogram
them without lifting off the security.

The security is set for both the Flash and the EEPROM by Flash location $FF0F.

Flash protection is set using Flash bytes $FF0A - $FF0D.
EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 05:45 11/10/2004 +0000, you wrote:
>Hello all,
>
>I am running in secure mode, however I need to write some parameters
>off to the EEPROM so that they aren't lost when the power goes off.
>So I want to unlock the chip, save the parameter, and then lock it up
>again.
>
>I am having problems with the unlocking side of things at the moment.
>As far as I understand I cannot unlock executing code in ROM, so I
>need copy the code into RAM and then execute it from there. This,
>however is causing me a fair few headaches in codewarrior.
>
>If anyone has an alternate method for saving variables into the
>EEPROM, or has done this before I would appreciate some help with the
>issue. >
>Currently to copy the ROM code into RAM I am
>using the following code: >void (*p1)(void);
>void (*p2)(void);
>
>*p1 = CodeInROM;
>p2 = (void *)0x3F00;
>
>memcpy(p2, p1, 64); >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM >
>thanks
>
>Mark





Hi Folks,
if I could chime in here, as I have been working with Mark on
this, but I know nothing about how CW does these things.
Unfortunately, the problem here stems from an errata, which states that in
secured mode the EEPROM and FLASH are not writable. This is for the earlier
mask set of the DP256.
So as the application requires the use of the EEPROM, he needs to write to
it while the device is secured.
So the need to unlock the chip using the backdoor keys. I can do this using
ICC12, copy a very small program to RAM and execute that. But we had no
luck using CW. Whatever we did the compiler undid! (That's not an accurate
description!)
Any help from the CW people would be appreciated.
Thanks.
PL At 10:01 AM 11/10/2004 +0300, you wrote:

>Mark,
>
>I believe there are two mechanisms in the HCS12 - Security, and Protection.
>
>Secured mode prevents external BDM or hardware from reading the content of
>your Flash and EEPROM.
>
>In addition, sections in the Flash and EEPROM can be protected against
>erase, and reprogramming, using the Protection mechanism.
>
>The two mechanisms are separate as far as I know. Thus, if you run in
>Secured mode, with the relevant EEPROM locations not protected (but still
>secured), you should be able to erase these EEPROM locations, and reprogram
>them without lifting off the security.
>
>The security is set for both the Flash and the EEPROM by Flash location $FF0F.
>
>Flash protection is set using Flash bytes $FF0A - $FF0D.
>EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
>
>Hope this helps,
>Doron
>Nohau Corporation
>HC12 In-Circuit Emulators
>www.nohau.com/emul12pc.html
>
>At 05:45 11/10/2004 +0000, you wrote:
> >Hello all,
> >
> >I am running in secure mode, however I need to write some parameters
> >off to the EEPROM so that they aren't lost when the power goes off.
> >So I want to unlock the chip, save the parameter, and then lock it up
> >again.
> >
> >I am having problems with the unlocking side of things at the moment.
> >As far as I understand I cannot unlock executing code in ROM, so I
> >need copy the code into RAM and then execute it from there. This,
> >however is causing me a fair few headaches in codewarrior.
> >
> >If anyone has an alternate method for saving variables into the
> >EEPROM, or has done this before I would appreciate some help with the
> >issue.
> >
> >
> >
> >Currently to copy the ROM code into RAM I am
> >using the following code:
> >
> >
> >void (*p1)(void);
> >void (*p2)(void);
> >
> >*p1 = CodeInROM;
> >p2 = (void *)0x3F00;
> >
> >memcpy(p2, p1, 64);
> >
> >
> >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> >
> >
> >
> >thanks
> >
> >Mark >Yahoo! Groups Links >
>





Hi Gillies
we have coded the keys in the application, so there is no need to
send them.
The problem is how do we load the program from the application flash, to
RAM and then tell CW that there is a function there. And so go and execute
it. I suspect that this is easy.... once you know how.
Thanks.
PL

At 10:02 AM 11/10/2004 +0200, you wrote: >Hi.
>
>Ok, found it in section "MUCts00604" in
>
>http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_0K7
>9X.pdf
>
>But the backdoor keep should be provided then to the chip SCI (or another
>protocol) (as the BDM is secured/disabled), something which can be done
>within a classic Terminal serial com tool.
>
>The debugger has a Terminal component, but it is not its genuine goal, and
>I bet an independent tool might be easier/faster to setup to send the key
>sequence.
>
>Regards,
>
>Gilles >At 09:19 AM 10/11/2004, you wrote:
>
> >Hi Folks,
> > if I could chime in here, as I have been working with Mark on
> >this, but I know nothing about how CW does these things.
> >Unfortunately, the problem here stems from an errata, which states that in
> >secured mode the EEPROM and FLASH are not writable. This is for the earlier
> >mask set of the DP256.
> >So as the application requires the use of the EEPROM, he needs to write to
> >it while the device is secured.
> >So the need to unlock the chip using the backdoor keys. I can do this using
> >ICC12, copy a very small program to RAM and execute that. But we had no
> >luck using CW. Whatever we did the compiler undid! (That's not an accurate
> >description!)
> >Any help from the CW people would be appreciated.
> >Thanks.
> >PL
> >
> >
> >At 10:01 AM 11/10/2004 +0300, you wrote:
> >
> > >Mark,
> > >
> > >I believe there are two mechanisms in the HCS12 - Security, and
> Protection.
> > >
> > >Secured mode prevents external BDM or hardware from reading the content of
> > >your Flash and EEPROM.
> > >
> > >In addition, sections in the Flash and EEPROM can be protected against
> > >erase, and reprogramming, using the Protection mechanism.
> > >
> > >The two mechanisms are separate as far as I know. Thus, if you run in
> > >Secured mode, with the relevant EEPROM locations not protected (but still
> > >secured), you should be able to erase these EEPROM locations, and
> reprogram
> > >them without lifting off the security.
> > >
> > >The security is set for both the Flash and the EEPROM by Flash location
> > $FF0F.
> > >
> > >Flash protection is set using Flash bytes $FF0A - $FF0D.
> > >EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
> > >
> > >Hope this helps,
> > >Doron
> > >Nohau Corporation
> > >HC12 In-Circuit Emulators
> > >www.nohau.com/emul12pc.html
> > >
> > >At 05:45 11/10/2004 +0000, you wrote:
> > > >Hello all,
> > > >
> > > >I am running in secure mode, however I need to write some parameters
> > > >off to the EEPROM so that they aren't lost when the power goes off.
> > > >So I want to unlock the chip, save the parameter, and then lock it up
> > > >again.
> > > >
> > > >I am having problems with the unlocking side of things at the moment.
> > > >As far as I understand I cannot unlock executing code in ROM, so I
> > > >need copy the code into RAM and then execute it from there. This,
> > > >however is causing me a fair few headaches in codewarrior.
> > > >
> > > >If anyone has an alternate method for saving variables into the
> > > >EEPROM, or has done this before I would appreciate some help with the
> > > >issue.
> > > >
> > > >
> > > >
> > > >Currently to copy the ROM code into RAM I am
> > > >using the following code:
> > > >
> > > >
> > > >void (*p1)(void);
> > > >void (*p2)(void);
> > > >
> > > >*p1 = CodeInROM;
> > > >p2 = (void *)0x3F00;
> > > >
> > > >memcpy(p2, p1, 64);
> > > >
> > > >
> > > >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> > > >
> > > >
> > > >
> > > >thanks
> > > >
> > > >Mark
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >Yahoo! Groups Links >
>






Hi.

Ok, found it in section "MUCts00604" in

http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_0K7
9X.pdf

But the backdoor keep should be provided then to the chip SCI (or another
protocol) (as the BDM is secured/disabled), something which can be done
within a classic Terminal serial com tool.

The debugger has a Terminal component, but it is not its genuine goal, and
I bet an independent tool might be easier/faster to setup to send the key
sequence.

Regards,

Gilles At 09:19 AM 10/11/2004, you wrote:

>Hi Folks,
> if I could chime in here, as I have been working with Mark on
>this, but I know nothing about how CW does these things.
>Unfortunately, the problem here stems from an errata, which states that in
>secured mode the EEPROM and FLASH are not writable. This is for the earlier
>mask set of the DP256.
>So as the application requires the use of the EEPROM, he needs to write to
>it while the device is secured.
>So the need to unlock the chip using the backdoor keys. I can do this using
>ICC12, copy a very small program to RAM and execute that. But we had no
>luck using CW. Whatever we did the compiler undid! (That's not an accurate
>description!)
>Any help from the CW people would be appreciated.
>Thanks.
>PL >At 10:01 AM 11/10/2004 +0300, you wrote:
>
> >Mark,
> >
> >I believe there are two mechanisms in the HCS12 - Security, and Protection.
> >
> >Secured mode prevents external BDM or hardware from reading the content of
> >your Flash and EEPROM.
> >
> >In addition, sections in the Flash and EEPROM can be protected against
> >erase, and reprogramming, using the Protection mechanism.
> >
> >The two mechanisms are separate as far as I know. Thus, if you run in
> >Secured mode, with the relevant EEPROM locations not protected (but still
> >secured), you should be able to erase these EEPROM locations, and reprogram
> >them without lifting off the security.
> >
> >The security is set for both the Flash and the EEPROM by Flash location
> $FF0F.
> >
> >Flash protection is set using Flash bytes $FF0A - $FF0D.
> >EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
> >
> >Hope this helps,
> >Doron
> >Nohau Corporation
> >HC12 In-Circuit Emulators
> >www.nohau.com/emul12pc.html
> >
> >At 05:45 11/10/2004 +0000, you wrote:
> > >Hello all,
> > >
> > >I am running in secure mode, however I need to write some parameters
> > >off to the EEPROM so that they aren't lost when the power goes off.
> > >So I want to unlock the chip, save the parameter, and then lock it up
> > >again.
> > >
> > >I am having problems with the unlocking side of things at the moment.
> > >As far as I understand I cannot unlock executing code in ROM, so I
> > >need copy the code into RAM and then execute it from there. This,
> > >however is causing me a fair few headaches in codewarrior.
> > >
> > >If anyone has an alternate method for saving variables into the
> > >EEPROM, or has done this before I would appreciate some help with the
> > >issue.
> > >
> > >
> > >
> > >Currently to copy the ROM code into RAM I am
> > >using the following code:
> > >
> > >
> > >void (*p1)(void);
> > >void (*p2)(void);
> > >
> > >*p1 = CodeInROM;
> > >p2 = (void *)0x3F00;
> > >
> > >memcpy(p2, p1, 64);
> > >
> > >
> > >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> > >
> > >
> > >
> > >thanks
> > >
> > >Mark
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >Yahoo! Groups Links





Hi Peter.

All understood. There is a code relocation issue here, I presume C-source
code, generated/linked for a flash address (i.e. to be flashed), then
function copied to ram to be executed from there (surely some absolute
addressing failure there).
For sure, you can write a PIC C-inlined assembler routine.
But in "full C", to my mind, the code/function should be linked at its
execution address, i.e. RAM, then be "offsetted" to flash for programming.

Let me check with Engineering about the correct solution for this issue.

Aside this issue: Sorry but I don't understand why it is necessary to copy
the code from flash to ram to execute it. I probably missed something.

Regards,

Gilles At 09:47 AM 10/11/2004, you wrote:

>Hi Gillies
> we have coded the keys in the application, so there is no need to
>send them.
>The problem is how do we load the program from the application flash, to
>RAM and then tell CW that there is a function there. And so go and execute
>it. I suspect that this is easy.... once you know how.
>Thanks.
>PL
>
>At 10:02 AM 11/10/2004 +0200, you wrote: > >Hi.
> >
> >Ok, found it in section "MUCts00604" in
> >
> >http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_0K7
> >9X.pdf
> >
> >But the backdoor keep should be provided then to the chip SCI (or another
> >protocol) (as the BDM is secured/disabled), something which can be done
> >within a classic Terminal serial com tool.
> >
> >The debugger has a Terminal component, but it is not its genuine goal, and
> >I bet an independent tool might be easier/faster to setup to send the key
> >sequence.
> >
> >Regards,
> >
> >Gilles
> >
> >
> >At 09:19 AM 10/11/2004, you wrote:
> >
> > >Hi Folks,
> > > if I could chime in here, as I have been working with Mark on
> > >this, but I know nothing about how CW does these things.
> > >Unfortunately, the problem here stems from an errata, which states that in
> > >secured mode the EEPROM and FLASH are not writable. This is for the
> earlier
> > >mask set of the DP256.
> > >So as the application requires the use of the EEPROM, he needs to write to
> > >it while the device is secured.
> > >So the need to unlock the chip using the backdoor keys. I can do this
> using
> > >ICC12, copy a very small program to RAM and execute that. But we had no
> > >luck using CW. Whatever we did the compiler undid! (That's not an accurate
> > >description!)
> > >Any help from the CW people would be appreciated.
> > >Thanks.
> > >PL
> > >
> > >
> > >At 10:01 AM 11/10/2004 +0300, you wrote:
> > >
> > > >Mark,
> > > >
> > > >I believe there are two mechanisms in the HCS12 - Security, and
> > Protection.
> > > >
> > > >Secured mode prevents external BDM or hardware from reading the
> content of
> > > >your Flash and EEPROM.
> > > >
> > > >In addition, sections in the Flash and EEPROM can be protected against
> > > >erase, and reprogramming, using the Protection mechanism.
> > > >
> > > >The two mechanisms are separate as far as I know. Thus, if you run in
> > > >Secured mode, with the relevant EEPROM locations not protected (but
> still
> > > >secured), you should be able to erase these EEPROM locations, and
> > reprogram
> > > >them without lifting off the security.
> > > >
> > > >The security is set for both the Flash and the EEPROM by Flash location
> > > $FF0F.
> > > >
> > > >Flash protection is set using Flash bytes $FF0A - $FF0D.
> > > >EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
> > > >
> > > >Hope this helps,
> > > >Doron
> > > >Nohau Corporation
> > > >HC12 In-Circuit Emulators
> > > >www.nohau.com/emul12pc.html
> > > >
> > > >At 05:45 11/10/2004 +0000, you wrote:
> > > > >Hello all,
> > > > >
> > > > >I am running in secure mode, however I need to write some parameters
> > > > >off to the EEPROM so that they aren't lost when the power goes off.
> > > > >So I want to unlock the chip, save the parameter, and then lock it up
> > > > >again.
> > > > >
> > > > >I am having problems with the unlocking side of things at the moment.
> > > > >As far as I understand I cannot unlock executing code in ROM, so I
> > > > >need copy the code into RAM and then execute it from there. This,
> > > > >however is causing me a fair few headaches in codewarrior.
> > > > >
> > > > >If anyone has an alternate method for saving variables into the
> > > > >EEPROM, or has done this before I would appreciate some help with the
> > > > >issue.
> > > > >
> > > > >
> > > > >
> > > > >Currently to copy the ROM code into RAM I am
> > > > >using the following code:
> > > > >
> > > > >
> > > > >void (*p1)(void);
> > > > >void (*p2)(void);
> > > > >
> > > > >*p1 = CodeInROM;
> > > > >p2 = (void *)0x3F00;
> > > > >
> > > > >memcpy(p2, p1, 64);
> > > > >
> > > > >
> > > > >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> > > > >
> > > > >
> > > > >
> > > > >thanks
> > > > >
> > > > >Mark
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >Yahoo! Groups Links





Thanks Gilles,
that's right on the money.
The problem comes with the execution of the unlock sequence. Where, after
the setting of the KEYACC bit, in the flash config reg, all accesses to the
flash are assumed to be writes to the key registers with the correct key
data. And reads return invalid data.
So access to the flash array for the next instruction does not work, but
returns 0x00.
I'd love to hear different, but this is my experience, little as it as. So
together with the errata and the method needed for the backdoor access, a
simple thing has become somewhat a task.
Thanks for your help.
Peter L.

At 10:36 AM 11/10/2004 +0200, you wrote: >Hi Peter.
>
>All understood. There is a code relocation issue here, I presume C-source
>code, generated/linked for a flash address (i.e. to be flashed), then
>function copied to ram to be executed from there (surely some absolute
>addressing failure there).
>For sure, you can write a PIC C-inlined assembler routine.
>But in "full C", to my mind, the code/function should be linked at its
>execution address, i.e. RAM, then be "offsetted" to flash for programming.
>
>Let me check with Engineering about the correct solution for this issue.
>
>Aside this issue: Sorry but I don't understand why it is necessary to copy
>the code from flash to ram to execute it. I probably missed something.
>
>Regards,
>
>Gilles >At 09:47 AM 10/11/2004, you wrote:
>
> >Hi Gillies
> > we have coded the keys in the application, so there is no need to
> >send them.
> >The problem is how do we load the program from the application flash, to
> >RAM and then tell CW that there is a function there. And so go and execute
> >it. I suspect that this is easy.... once you know how.
> >Thanks.
> >PL
> >
> >At 10:02 AM 11/10/2004 +0200, you wrote:
> >
> >
> > >Hi.
> > >
> > >Ok, found it in section "MUCts00604" in
> > >
> > >http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256
> B_0K7
> > >9X.pdf
> > >
> > >But the backdoor keep should be provided then to the chip SCI (or another
> > >protocol) (as the BDM is secured/disabled), something which can be done
> > >within a classic Terminal serial com tool.
> > >
> > >The debugger has a Terminal component, but it is not its genuine goal, and
> > >I bet an independent tool might be easier/faster to setup to send the key
> > >sequence.
> > >
> > >Regards,
> > >
> > >Gilles
> > >
> > >
> > >At 09:19 AM 10/11/2004, you wrote:
> > >
> > > >Hi Folks,
> > > > if I could chime in here, as I have been working with Mark on
> > > >this, but I know nothing about how CW does these things.
> > > >Unfortunately, the problem here stems from an errata, which states
> that in
> > > >secured mode the EEPROM and FLASH are not writable. This is for the
> > earlier
> > > >mask set of the DP256.
> > > >So as the application requires the use of the EEPROM, he needs to
> write to
> > > >it while the device is secured.
> > > >So the need to unlock the chip using the backdoor keys. I can do this
> > using
> > > >ICC12, copy a very small program to RAM and execute that. But we had no
> > > >luck using CW. Whatever we did the compiler undid! (That's not an
> accurate
> > > >description!)
> > > >Any help from the CW people would be appreciated.
> > > >Thanks.
> > > >PL
> > > >
> > > >
> > > >At 10:01 AM 11/10/2004 +0300, you wrote:
> > > >
> > > > >Mark,
> > > > >
> > > > >I believe there are two mechanisms in the HCS12 - Security, and
> > > Protection.
> > > > >
> > > > >Secured mode prevents external BDM or hardware from reading the
> > content of
> > > > >your Flash and EEPROM.
> > > > >
> > > > >In addition, sections in the Flash and EEPROM can be protected against
> > > > >erase, and reprogramming, using the Protection mechanism.
> > > > >
> > > > >The two mechanisms are separate as far as I know. Thus, if you run in
> > > > >Secured mode, with the relevant EEPROM locations not protected (but
> > still
> > > > >secured), you should be able to erase these EEPROM locations, and
> > > reprogram
> > > > >them without lifting off the security.
> > > > >
> > > > >The security is set for both the Flash and the EEPROM by Flash
> location
> > > > $FF0F.
> > > > >
> > > > >Flash protection is set using Flash bytes $FF0A - $FF0D.
> > > > >EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
> > > > >
> > > > >Hope this helps,
> > > > >Doron
> > > > >Nohau Corporation
> > > > >HC12 In-Circuit Emulators
> > > > >www.nohau.com/emul12pc.html
> > > > >
> > > > >At 05:45 11/10/2004 +0000, you wrote:
> > > > > >Hello all,
> > > > > >
> > > > > >I am running in secure mode, however I need to write some parameters
> > > > > >off to the EEPROM so that they aren't lost when the power goes off.
> > > > > >So I want to unlock the chip, save the parameter, and then lock
> it up
> > > > > >again.
> > > > > >
> > > > > >I am having problems with the unlocking side of things at the
> moment.
> > > > > >As far as I understand I cannot unlock executing code in ROM, so I
> > > > > >need copy the code into RAM and then execute it from there. This,
> > > > > >however is causing me a fair few headaches in codewarrior.
> > > > > >
> > > > > >If anyone has an alternate method for saving variables into the
> > > > > >EEPROM, or has done this before I would appreciate some help
> with the
> > > > > >issue.
> > > > > >
> > > > > >
> > > > > >
> > > > > >Currently to copy the ROM code into RAM I am
> > > > > >using the following code:
> > > > > >
> > > > > >
> > > > > >void (*p1)(void);
> > > > > >void (*p2)(void);
> > > > > >
> > > > > >*p1 = CodeInROM;
> > > > > >p2 = (void *)0x3F00;
> > > > > >
> > > > > >memcpy(p2, p1, 64);
> > > > > >
> > > > > >
> > > > > >__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> > > > > >
> > > > > >
> > > > > >
> > > > > >thanks
> > > > > >
> > > > > >Mark
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >Yahoo! Groups Links >
>




As the HC12 Compiler can generate PIC code, I would suggest something
like this:

#include <string.h> /* for memcpy */

#pragma CODE_SEG __NEAR_SEG __PIC_SEG MY_PIC_SEC
void test1(void);
void test2(void) { /* make a call just to show it is PIC */
test1();
}
void test1(void) {
}
#pragma CODE_SEG DEFAULT

char codeBuf[100];
extern char __SEG_START_MY_PIC_SEC[];
extern char __SEG_SIZE_MY_PIC_SEC[];

void RunItInRam(void) {
(void)memcpy(codeBuf, test2, (int)__SEG_SIZE_MY_PIC_SEC);
(*(void(*__near)(void))__SEG_START_MY_PIC_SEC) ();
} Bye

Daniel

Gilles Blanquin wrote:

>Hi Peter.
>
>All understood. There is a code relocation issue here, I presume C-source
>code, generated/linked for a flash address (i.e. to be flashed), then
>function copied to ram to be executed from there (surely some absolute
>addressing failure there).
>For sure, you can write a PIC C-inlined assembler routine.
>But in "full C", to my mind, the code/function should be linked at its
>execution address, i.e. RAM, then be "offsetted" to flash for programming.
>
>Let me check with Engineering about the correct solution for this issue.
>
>Aside this issue: Sorry but I don't understand why it is necessary to copy
>the code from flash to ram to execute it. I probably missed something.
>
>Regards,
>
>Gilles >At 09:47 AM 10/11/2004, you wrote: >
>>Hi Gillies
>> we have coded the keys in the application, so there is no need to
>>send them.
>>The problem is how do we load the program from the application flash, to
>>RAM and then tell CW that there is a function there. And so go and execute
>>it. I suspect that this is easy.... once you know how.
>>Thanks.
>>PL
>>
>>At 10:02 AM 11/10/2004 +0200, you wrote:
>>
>>
>>
>>
>>>Hi.
>>>
>>>Ok, found it in section "MUCts00604" in
>>>
>>>http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_0K7
>>>9X.pdf
>>>
>>>But the backdoor keep should be provided then to the chip SCI (or another
>>>protocol) (as the BDM is secured/disabled), something which can be done
>>>within a classic Terminal serial com tool.
>>>
>>>The debugger has a Terminal component, but it is not its genuine goal, and
>>>I bet an independent tool might be easier/faster to setup to send the key
>>>sequence.
>>>
>>>Regards,
>>>
>>>Gilles
>>>
>>>
>>>At 09:19 AM 10/11/2004, you wrote:
>>>
>>>
>>>
>>>>Hi Folks,
>>>> if I could chime in here, as I have been working with Mark on
>>>>this, but I know nothing about how CW does these things.
>>>>Unfortunately, the problem here stems from an errata, which states that in
>>>>secured mode the EEPROM and FLASH are not writable. This is for the
>>>>
>>>>
>>earlier
>>
>>
>>>>mask set of the DP256.
>>>>So as the application requires the use of the EEPROM, he needs to write to
>>>>it while the device is secured.
>>>>So the need to unlock the chip using the backdoor keys. I can do this
>>>>
>>>>
>>using
>>
>>
>>>>ICC12, copy a very small program to RAM and execute that. But we had no
>>>>luck using CW. Whatever we did the compiler undid! (That's not an accurate
>>>>description!)
>>>>Any help from the CW people would be appreciated.
>>>>Thanks.
>>>>PL
>>>>
>>>>
>>>>At 10:01 AM 11/10/2004 +0300, you wrote:
>>>>
>>>>
>>>>
>>>>>Mark,
>>>>>
>>>>>I believe there are two mechanisms in the HCS12 - Security, and
>>>>>
>>>>>
>>>Protection.
>>>
>>>
>>>>>Secured mode prevents external BDM or hardware from reading the
>>>>>
>>>>>
>>content of
>>
>>
>>>>>your Flash and EEPROM.
>>>>>
>>>>>In addition, sections in the Flash and EEPROM can be protected against
>>>>>erase, and reprogramming, using the Protection mechanism.
>>>>>
>>>>>The two mechanisms are separate as far as I know. Thus, if you run in
>>>>>Secured mode, with the relevant EEPROM locations not protected (but
>>>>>
>>>>>
>>still
>>
>>
>>>>>secured), you should be able to erase these EEPROM locations, and
>>>>>
>>>>>
>>>reprogram
>>>
>>>
>>>>>them without lifting off the security.
>>>>>
>>>>>The security is set for both the Flash and the EEPROM by Flash location
>>>>>
>>>>>
>>>>$FF0F.
>>>>
>>>>
>>>>>Flash protection is set using Flash bytes $FF0A - $FF0D.
>>>>>EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
>>>>>
>>>>>Hope this helps,
>>>>>Doron
>>>>>Nohau Corporation
>>>>>HC12 In-Circuit Emulators
>>>>>www.nohau.com/emul12pc.html
>>>>>
>>>>>At 05:45 11/10/2004 +0000, you wrote:
>>>>>
>>>>>
>>>>>>Hello all,
>>>>>>
>>>>>>I am running in secure mode, however I need to write some parameters
>>>>>>off to the EEPROM so that they aren't lost when the power goes off.
>>>>>>So I want to unlock the chip, save the parameter, and then lock it up
>>>>>>again.
>>>>>>
>>>>>>I am having problems with the unlocking side of things at the moment.
>>>>>>As far as I understand I cannot unlock executing code in ROM, so I
>>>>>>need copy the code into RAM and then execute it from there. This,
>>>>>>however is causing me a fair few headaches in codewarrior.
>>>>>>
>>>>>>If anyone has an alternate method for saving variables into the
>>>>>>EEPROM, or has done this before I would appreciate some help with the
>>>>>>issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>Currently to copy the ROM code into RAM I am
>>>>>>using the following code:
>>>>>>
>>>>>>
>>>>>>void (*p1)(void);
>>>>>>void (*p2)(void);
>>>>>>
>>>>>>*p1 = CodeInROM;
>>>>>>p2 = (void *)0x3F00;
>>>>>>
>>>>>>memcpy(p2, p1, 64);
>>>>>>
>>>>>>
>>>>>>__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
>>>>>>
>>>>>>
>>>>>>
>>>>>>thanks
>>>>>>
>>>>>>Mark
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
> >Yahoo! Groups Links >
>





Thanks Daniel,
that will help Mark solve the problem. (He would have gone home by
now, but he'll see it in the morning.)
Thanks again.
Peter L. At 10:57 AM 11/10/2004 +0200, you wrote:

>As the HC12 Compiler can generate PIC code, I would suggest something
>like this:
>
>#include <string.h> /* for memcpy */
>
>#pragma CODE_SEG __NEAR_SEG __PIC_SEG MY_PIC_SEC
>void test1(void);
>void test2(void) { /* make a call just to show it is PIC */
> test1();
>}
>void test1(void) {
>}
>#pragma CODE_SEG DEFAULT
>
>char codeBuf[100];
>extern char __SEG_START_MY_PIC_SEC[];
>extern char __SEG_SIZE_MY_PIC_SEC[];
>
>void RunItInRam(void) {
> (void)memcpy(codeBuf, test2, (int)__SEG_SIZE_MY_PIC_SEC);
> (*(void(*__near)(void))__SEG_START_MY_PIC_SEC) ();
>} >Bye
>
>Daniel
>
>Gilles Blanquin wrote:
>
> >Hi Peter.
> >
> >All understood. There is a code relocation issue here, I presume C-source
> >code, generated/linked for a flash address (i.e. to be flashed), then
> >function copied to ram to be executed from there (surely some absolute
> >addressing failure there).
> >For sure, you can write a PIC C-inlined assembler routine.
> >But in "full C", to my mind, the code/function should be linked at its
> >execution address, i.e. RAM, then be "offsetted" to flash for programming.
> >
> >Let me check with Engineering about the correct solution for this issue.
> >
> >Aside this issue: Sorry but I don't understand why it is necessary to copy
> >the code from flash to ram to execute it. I probably missed something.
> >
> >Regards,
> >
> >Gilles
> >
> >
> >At 09:47 AM 10/11/2004, you wrote:
> >
> >
> >
> >>Hi Gillies
> >> we have coded the keys in the application, so there is no need to
> >>send them.
> >>The problem is how do we load the program from the application flash, to
> >>RAM and then tell CW that there is a function there. And so go and execute
> >>it. I suspect that this is easy.... once you know how.
> >>Thanks.
> >>PL
> >>
> >>At 10:02 AM 11/10/2004 +0200, you wrote:
> >>
> >>
> >>
> >>
> >>>Hi.
> >>>
> >>>Ok, found it in section "MUCts00604" in
> >>>
> >>>http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256
> B_0K7
> >>>9X.pdf
> >>>
> >>>But the backdoor keep should be provided then to the chip SCI (or another
> >>>protocol) (as the BDM is secured/disabled), something which can be done
> >>>within a classic Terminal serial com tool.
> >>>
> >>>The debugger has a Terminal component, but it is not its genuine goal, and
> >>>I bet an independent tool might be easier/faster to setup to send the key
> >>>sequence.
> >>>
> >>>Regards,
> >>>
> >>>Gilles
> >>>
> >>>
> >>>At 09:19 AM 10/11/2004, you wrote:
> >>>
> >>>
> >>>
> >>>>Hi Folks,
> >>>> if I could chime in here, as I have been working with Mark on
> >>>>this, but I know nothing about how CW does these things.
> >>>>Unfortunately, the problem here stems from an errata, which states
> that in
> >>>>secured mode the EEPROM and FLASH are not writable. This is for the
> >>>>
> >>>>
> >>earlier
> >>
> >>
> >>>>mask set of the DP256.
> >>>>So as the application requires the use of the EEPROM, he needs to
> write to
> >>>>it while the device is secured.
> >>>>So the need to unlock the chip using the backdoor keys. I can do this
> >>>>
> >>>>
> >>using
> >>
> >>
> >>>>ICC12, copy a very small program to RAM and execute that. But we had no
> >>>>luck using CW. Whatever we did the compiler undid! (That's not an
> accurate
> >>>>description!)
> >>>>Any help from the CW people would be appreciated.
> >>>>Thanks.
> >>>>PL
> >>>>
> >>>>
> >>>>At 10:01 AM 11/10/2004 +0300, you wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Mark,
> >>>>>
> >>>>>I believe there are two mechanisms in the HCS12 - Security, and
> >>>>>
> >>>>>
> >>>Protection.
> >>>
> >>>
> >>>>>Secured mode prevents external BDM or hardware from reading the
> >>>>>
> >>>>>
> >>content of
> >>
> >>
> >>>>>your Flash and EEPROM.
> >>>>>
> >>>>>In addition, sections in the Flash and EEPROM can be protected against
> >>>>>erase, and reprogramming, using the Protection mechanism.
> >>>>>
> >>>>>The two mechanisms are separate as far as I know. Thus, if you run in
> >>>>>Secured mode, with the relevant EEPROM locations not protected (but
> >>>>>
> >>>>>
> >>still
> >>
> >>
> >>>>>secured), you should be able to erase these EEPROM locations, and
> >>>>>
> >>>>>
> >>>reprogram
> >>>
> >>>
> >>>>>them without lifting off the security.
> >>>>>
> >>>>>The security is set for both the Flash and the EEPROM by Flash location
> >>>>>
> >>>>>
> >>>>$FF0F.
> >>>>
> >>>>
> >>>>>Flash protection is set using Flash bytes $FF0A - $FF0D.
> >>>>>EEPROM protection is set using EEPROM byte (EEPROM BASE + $0FFD).
> >>>>>
> >>>>>Hope this helps,
> >>>>>Doron
> >>>>>Nohau Corporation
> >>>>>HC12 In-Circuit Emulators
> >>>>>www.nohau.com/emul12pc.html
> >>>>>
> >>>>>At 05:45 11/10/2004 +0000, you wrote:
> >>>>>
> >>>>>
> >>>>>>Hello all,
> >>>>>>
> >>>>>>I am running in secure mode, however I need to write some parameters
> >>>>>>off to the EEPROM so that they aren't lost when the power goes off.
> >>>>>>So I want to unlock the chip, save the parameter, and then lock it up
> >>>>>>again.
> >>>>>>
> >>>>>>I am having problems with the unlocking side of things at the moment.
> >>>>>>As far as I understand I cannot unlock executing code in ROM, so I
> >>>>>>need copy the code into RAM and then execute it from there. This,
> >>>>>>however is causing me a fair few headaches in codewarrior.
> >>>>>>
> >>>>>>If anyone has an alternate method for saving variables into the
> >>>>>>EEPROM, or has done this before I would appreciate some help with the
> >>>>>>issue.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Currently to copy the ROM code into RAM I am
> >>>>>>using the following code:
> >>>>>>
> >>>>>>
> >>>>>>void (*p1)(void);
> >>>>>>void (*p2)(void);
> >>>>>>
> >>>>>>*p1 = CodeInROM;
> >>>>>>p2 = (void *)0x3F00;
> >>>>>>
> >>>>>>memcpy(p2, p1, 64);
> >>>>>>
> >>>>>>
> >>>>>>__asm JSR 0x3f00; //to execute the function "CodeInROM" in RAM
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>thanks
> >>>>>>
> >>>>>>Mark
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Yahoo! Groups Links
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links >
>