Vector Redirection and Memory Protection

[Saga]

Hi to all, i'm having trouble, what i want to do is to redirect the vector table after i protect the memory... i've read the datasheet but i'm kinda lost with the code, do you have an example code that does that?? i will really appreciate it, also what i want to do is once i redirect the vector table i want to change the direction where the interrupts go, for example i want to have 2 interrupt functions that catch the "old" vector (before i redirect it) and one interrupt function that catch the new vector (once i redirected it) but i'm really newbie at this hobbie and i've never catched an interrupt before... so i really need help with this one... Like i said before i do have experience with c/c++ but not with this kind of coding which i find really interesting...

Thank you a lot guys, so far, i've learned a lot in this forum!

[jah]

vector redirection and security may conflict, get the redirection working before security.

on a secure part (m0xFFBF=0xFC) consider using the security back door function when you move the vector table in flash. i just posted my effort on a mc9s08rd32dwe processor. things that i got confusted:
1)the lo level code to do the backdoor needs to emulate out of ram. write it in assembly language to avoid certain bad instructions. it will take about 50bytes of instruction, put this in a c language array and have the linker write it at processor power up to ram auto magic. refrence my posting.
2)0xFFBF = 0xFC for security set, 0xFE for security off
3)create a c language const array to assert flash 0xFFB0 through 0xFFBF to your settings, this includes the super secret 8byte code to operate the backdoor.

[tonyp]

Vector redirection is, unfortunately, not implemented as one would normally assume.  You can't have two sets of vectors, only one.  The reset vector is always in the protected (old) code, and all other vectors are in the unprotected (new) code.  This has been a compaint of mine all along.  Whoever designed this vector redirection method hadn't have enough sleep the night before.  S/he assumed that one would be interested in only a *single* version of the code, the unprotected (new) one.  The protected (old) code would be doomed to work without interrupts, and thus be limited to very basic functions of little complexity.

To achieve what you describe, you have to do it "manually," i.e., forget hardware vector redirection, and use software redirection that you can switch on/off yourself.  This means, adding JMPs to original vectors after checking (via a flag someplace) which vector to execute.

Hardware vector redirection would have been a lot more useful had it been dynamic, i.e., a single write-once bit in some control register is one solution.  The better solution would be for this switch to occur once the PC register is first loaded with any address in the unprotected region (indicating we have left the protected region).  This would have allowed for two fully working sets of code to co-exist, and true redirection.

Message Edited by tonyp on 2006-11-1409:56 AM

[Saga]

Thank you tonyp... Yes, it is like that... but, strangely, the actual implementation of vector redirection fills my needs...

What i just want is just like once i protect the code a timer interrupt goes to another function for example:

interrupt 25 void old_timer_interrupt ();
interrupt 25 void new_timer_interrupt ();

What i want to do is once i protect the code and i redirect the vectors, the same timer interrupt goes to the new_timer_interrupt(); instead of the old_timer_interrupt();... In theory i know how to do that... I have to change the new vector interrupt to go to the new function but i do not know how to do this in the practice... Also i have to put in the PRM something like this

VECTOR 25 old_timer_interrupt

but do i have to put VECTOR 25 new_timer_interrupt ?? or how do i tell them that once that i protect some memory and redirect the vectors to go to the new_timer_interrupt() ?? thats my question... I hope some of you guys could give me an example code about that... it will be really appreciated. Thanks for reading!

[tonyp]

Can't help you with your compiler, but this may also be a function of the bootloader, and you may not have to do anything in your code (other than enable vector redirection).  My bootloader, for example, automatically redirects vectors to their new location during loading, so that vector at $FFFA ends up at $xFFA where x is based on whatever redirection the bootloader has enabled (to protect itself).

Someone else will hopefully provide you with compiler specific instructions, if appropriate.

[Saga]

I hope so

I appreciate your help too... I'm figuring it out myself though if i find the way ill post it in the forum... i'm pretty sure it will help another's too.

[yb]

Hi Saga,

If you are using 9S08 (GB, QG, AW), vectors redirection functionnality is "included" into the chip (bit FNORED in NOVPT register).

Regards,

[mBeppe]

hi All

I use mc9s08ac96 but not find bit FNORED in NOVPT register. This is used "KEYEN"

on mc9s08ac32 this bit exist.

Alternative fo redirect Vectors ?

Ciao

[tonyp]

It seems that all MMU enabled variants do NOT have vector redirection capability in hardware.  This may have something to do with the presence of a page window which would make the redirected vectors occasionally land inside a page, a big NO-NO.

So, the software alternative is to do this for each vector you want to redirect:

ISR_Routine         ...                    rtiSoftVector          dw        ISR_Routine                    ...Redirect_1          lda       SoftVector+1        ;LSB of ISR address                    psha                    lda       SoftVector          ;MSB of ISR address                    psha                    RTS                           ;Call ISRHardVector_1        dw        Redirect_1

[bigmac]

Hello TonyP,

What would be the disadvantage of using a simple jump to the re-directed ISR routine?  Alternatively, the routine call could use JSR (with the ISR_Routine ending with RTS, rather than RTI).  These possibilities would seem more straight forward - perhaps something like the following code for the jump case.

ISR_Routine         ...                    rtiRedirect_1          jmp    ISR_RoutineHardVector_1        dc.w   Redirect_1

For C coding, maybe the following:

void ISR_func( void){   ...}interrupt Interrupt_number Redirect_1( void){   __asm jsr ISR_func;}

 The various Redirect functions would need to be placed at predetermined positions known in advance to the entry code.

Regards,

Mac

[tonyp]

---

bigmac wrote:

Hello TonyP,

What would be the disadvantage of using a simple jump to the re-directed ISR routine?

...

The various Redirect functions would need to be placed at predetermined positions known in advance to the entry code.

---

I think you answered it yourself: Having the ISRs at fixed locations.

Firmware upgrades would be unnecessarily more difficult to organize so that any improved / modified ISRs with a new size would fall on the exact same location(s).

An alternative would be to use an indirect JMP (a JMP to a table of JMPs), but the table entries would require 3 bytes, so you can't simply relocate the original hardware vectors by adding (subtracting) an offset.  Why not keep things simpler?  (It more closely resembles the hardware redirection.)

[bigmac]

Hello TonyP,

There seems to be a significant misinterpretation of my previously posted suggestion.  There is no requirement for the ISR functions, designated by ISR_func() or ISR_Routine, to be placed at fixed locations.  I did not say this.  The position of each ISR function need only be known to the application program, and not the boot loader.

In your case, the SoftVector table would be located within the application area, and the position of each table entry would need to be known in advance by the boot loader code.  However, your code has the additional Redirect routines within the boot loader area, that are referenced by the normal interrupt vectors.  A consequence of this approach is that similar routines must be included for every interrupt vector, since the boot loader does not know in advance which interrupts would be required by the application.  This would result in an increase in bootloader code size by maybe up to 280 bytes.

For the alternative approach, the Redirect routines would each occupy three bytes (or four bytes should a JSR instruction be used), and these routines would be located in a jump table within the application area.  This table would at a known location, usually immediately below the boot loader code - a very similar scenario to your SoftVector table.

The primary difference between the two approaches is that all interrupts, that do not require interception by the boot loader, may vector directly to the jump table within the application area, resulting in simplification of the boot loader code, and reduced code size.

The trade off would therefore appear to be either a slightly more complex jump table structure, versus an increase in the boot loader code size.

Regards,

Mac