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
> > >
> > >
> > >
> > >
|