Message Edited by tonyp on 2006-11-1409:56 AM
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
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
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
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.)
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