|
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 |
|
|
MC9S12DP256 unlocking problems
Started by ●October 11, 2004
Reply by ●October 11, 20042004-10-11
|
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 |
|
|
Reply by ●October 11, 20042004-10-11
|
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 |
|
|
Reply by ●October 11, 20042004-10-11
|
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 > > |
|
|
Reply by ●October 11, 20042004-10-11
|
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 > > |
|
|
Reply by ●October 11, 20042004-10-11
|
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 |
Reply by ●October 11, 20042004-10-11
|
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 |
|
|
Reply by ●October 11, 20042004-10-11
|
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 > > |
Reply by ●October 11, 20042004-10-11
|
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 > > |
|
|
Reply by ●October 11, 20042004-10-11
|
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 > > |
|
|
