|
Thanks you all for your help. I am however still having some problems with that code Daniel wrote. From looking at the assembly and the registers running on the execution of this line of code: (*(void(*__near)(void))__SEG_START_MY_PIC_SEC) (); it is still trying to execute this code on PPAGE 32, not from RAM. I have tried making a function pointer point to the start of the codeBuff[] array, and then executing the pointer: ie. void (*pFunctionInRAM)(void); *pFunctionInRAM = (void *)codeBuf; (void)memcpy(codeBuf, test2, (int)__SEG_SIZE_MY_PIC_SEC); pFunctionInRAM(); , but this does not work either. Any further help would be appreciated. Thanks, Mark --- In , Peter Lissenburg <peter@s...> wrote: > 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 > > > > > > > > |
|
|
MC9S12DP256 unlocking problems
Started by ●October 11, 2004
Reply by ●October 11, 20042004-10-11
Reply by ●October 12, 20042004-10-12
|
OK - I fixed it thank you all for helping - a lot of pushes in the right direction has done it for me. The end result looks like this to get a segment of code to be exectued from RAM. #pragma CODE_SEG NON_BANKED char codeBuf[100]; extern char __SEG_START_NEW_SEG[]; //NEW_SEG contains function with the code to run in RAM extern char __SEG_SIZE_NEW_SEG[]; void RunItInRam(void) { int i; char* startOfCopyCode = (char*)__SEG_START_NEW_SEG; for(i=0 ; i<=(int)__SEG_SIZE_NEW_SEG ; i++) { codeBuf[i] = *startOfCopyCode++; } (*(void(*__near)(void))codeBuf) (); //executes what has just been copied into codeBuf array } --- In , "markstaples999" <mstaples@s...> wrote: > > Thanks you all for your help. > > I am however still having some problems with that code Daniel wrote. > From looking at the assembly and the registers running on the > execution of this line of code: > (*(void(*__near)(void))__SEG_START_MY_PIC_SEC) (); > > it is still trying to execute this code on PPAGE 32, not from RAM. > > I have tried making a function pointer point to the start of the > codeBuff[] array, and then executing the pointer: > > ie. > void (*pFunctionInRAM)(void); > > *pFunctionInRAM = (void *)codeBuf; > > (void)memcpy(codeBuf, test2, (int)__SEG_SIZE_MY_PIC_SEC); > > pFunctionInRAM(); > , but this does not work either. > Any further help would be appreciated. > > Thanks, > Mark > --- In , Peter Lissenburg <peter@s...> wrote: > > 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 > > > > > > > > > > > > |
Reply by ●October 13, 20042004-10-13
|
Hi all, I really the "same block" restriction ?. (i.e. program executing in one specific block cannot modify flash in same block). Where is it docummented ? If so, it will explain RAM executing requirement. I found in DG256 ( 4 x 64 KB blocks) that if I try to erase/write data in flash page 0x3c from not paged code in 0x4000 (both in memory block 0x00), FSTAT ACCERR bit (@0x105) is set as soon any bank select operation is done (FCNFG @ 0x103, BKSEL1 = BKSEL0 = 0). (Security & Protection show FSEC @ 0x101 = 0xFE and FPROT @ 0x104 = 0xFF) Same operations in blocks 1 to 3 (pages 0x30 to 0x3B) are successfull. Regards, Jordi Costa ----- Original Message ----- From: "Gilles Blanquin" <> > 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. > 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. > |
|
|
Reply by ●October 13, 20042004-10-13
|
Hi Jordi. From the "S12FTS256KV2.pdf" specifications (extract here below). Last-but-one sentence. Regards, Gilles Block User Guide HCS12FTS256KUG V02.01 Section 1 Introduction 1.1 Overview This document describes the FTS256K module which is a 256k byte Flash (Non-Volatile) Memory. The Flash array is organized as 4 blocks of 64k bytes. Each block is organized as 1024 rows of 64 bytes. The Flash blocks erase sector size is 8 rows (512 bytes). The Flash memory may be read as either bytes, aligned words or misaligned words. Read access time is one bus cycle for byte and aligned word, and two bus cycles for misaligned words. Program and erase functions are controlled by a command driven interface. Both sector erase and mass erase of an entire 64k byte Flash block are supported. An erased bit reads 1 and a programmed bit reads 0. The high voltage required to program and erase is generated internally by on-chip charge pumps. All Flash blocks can be programmed or erased at the same time, however it is not possible to read from a Flash block while it is being erased or programmed. The Flash is ideal for program and data storage for single-supply applications allowing for field reprogramming without requiring external programming voltage sources. At 09:25 AM 10/13/2004, you wrote: >Hi all, > >I really the "same block" restriction ?. (i.e. program executing in one >specific block cannot modify flash in same block). Where is it docummented ? > >If so, it will explain RAM executing requirement. > >I found in DG256 ( 4 x 64 KB blocks) that if I try to erase/write data in >flash page 0x3c from not paged code in 0x4000 (both in memory block 0x00), >FSTAT ACCERR bit (@0x105) is set as soon any bank select operation is done >(FCNFG @ 0x103, BKSEL1 = BKSEL0 = 0). >(Security & Protection show FSEC @ 0x101 = 0xFE and FPROT @ 0x104 = 0xFF) > >Same operations in blocks 1 to 3 (pages 0x30 to 0x3B) are successfull. > >Regards, > >Jordi Costa >----- Original Message ----- >From: "Gilles Blanquin" <> > > > 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. > > > 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. > > > >Yahoo! Groups Links |
Reply by ●October 13, 20042004-10-13
|
Thanks Gilles. I just found that Motorola AN2153 states: "Even though FLASH block zero has two separate erase protected areas, code cannot be run out of either protected area while the remainder of the block is erased or programmed." and thus justifies RAM execution of bootloader. Regards, Jordi ----- Original Message ----- From: "Gilles Blanquin" <> To: <> Sent: Wednesday, October 13, 2004 10:43 AM Subject: Re: [68HC12] MC9S12DP256 unlocking problems Hi Jordi. From the "S12FTS256KV2.pdf" specifications (extract here below). Last-but-one sentence. Regards, Gilles Block User Guide - HCS12FTS256KUG V02.01 Section 1 Introduction 1.1 Overview This document describes the FTS256K module which is a 256k byte Flash (Non-Volatile) Memory. The Flash array is organized as 4 blocks of 64k bytes. Each block is organized as 1024 rows of 64 bytes. The Flash block's erase sector size is 8 rows (512 bytes). The Flash memory may be read as either bytes, aligned words or misaligned words. Read access time is one bus cycle for byte and aligned word, and two bus cycles for misaligned words. Program and erase functions are controlled by a command driven interface. Both sector erase and mass erase of an entire 64k byte Flash block are supported. An erased bit reads '1' and a programmed bit reads '0'. The high voltage required to program and erase is generated internally by on-chip charge pumps. All Flash blocks can be programmed or erased at the same time, however it is not possible to read from a Flash block while it is being erased or programmed. The Flash is ideal for program and data storage for single-supply applications allowing for field reprogramming without requiring external programming voltage sources. At 09:25 AM 10/13/2004, you wrote: >Hi all, > >I really the "same block" restriction ?. (i.e. program executing in one >specific block cannot modify flash in same block). Where is it docummented ? > >If so, it will explain RAM executing requirement. > >I found in DG256 ( 4 x 64 KB blocks) that if I try to erase/write data in >flash page 0x3c from not paged code in 0x4000 (both in memory block 0x00), >FSTAT ACCERR bit (@0x105) is set as soon any bank select operation is done >(FCNFG @ 0x103, BKSEL1 = BKSEL0 = 0). >(Security & Protection show FSEC @ 0x101 = 0xFE and FPROT @ 0x104 = 0xFF) > >Same operations in blocks 1 to 3 (pages 0x30 to 0x3B) are successfull. > >Regards, > >Jordi Costa >----- Original Message ----- >From: "Gilles Blanquin" <> > > > 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. > > > 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. > > > >Yahoo! Groups Links Yahoo! Groups Links |
