Does the 9S08PA60 support Vector Redirection?

[KrisRutecki]

Hello,

I can't find any information whether the new 9S08PA60 supports vector redirection.

If so where is the FNORED bit or what is the mechanism? Wasted whole day searching for the answer...

Thanks, Kris

[KrisRutecki · Accepted solution]

Here is the service request final result from Jennie...

For what it is worth, even the support was confused and the 1st replay was that it does.

-----

PA60 doesn’t have vector redirection feature. It uses vector jumping table to implement vector relocation.

I recommend a useful document
http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4440.pdf

----

Thank you all once again.

P.S.As far as Freescale is concerned the NVM_FOPT register does nothing

to the hardware on the MC9S08PA60 micro. Writing any value is ok  there.

[tonyp]

I had the same problem many years ago with the QE series where the members from the 60K and up (i.e., MMU enabled) did not support vector redirection while the smaller ones did.

I assume it is the same in your case.

What I ended up doing was implement my own software based vector redirection which only adds a few cycles of latency to the various ISRs.

[KrisRutecki]

The reference manual completely ignores the Vector relocation issue.

I need to know this so I can implement a bootloader which does not have to erase everything before  being able to write.

Rather then go your route I have over the years written bootloaders which not only run from RAM (all pretty much have to) but also wipe the entire flash clean. Problem with this approach  is your power can't go down while you are programming. If it does then you have to program using a standard Freescale method. Hence it is much safer to use the Vector relocation capability. If it exists.... Now, does it?

[tonyp]

If the manual does not mention vector redirection or vector relocation then it most certainly isn't supported.  (The two go together.)

But, I'm afraid you didn't quite understand my suggestion.

I too have been using my own bootloader (for years) and, for the QE128 (in my case), I have implemented a software redirection which also includes vector relocation.  So, as far as the application is concerned, it is written as if vector redirection were supported.

The bootloader Flash section is protected so it can not be erased, and losing power in the middle of the process can not become an issue.  You simply restart the process.  In effect, it behaves exactly the same as if vector redirection and the related vector relocation were available.

How it works:

Each real vector (except reset, obviously) jumps to a corresponding routine in protected Flash that loads the corresponding relocated vector from unprotected Flash (where they would be if the feature was available), and then jumps to it using code like this (which does not destroy caller's H):

	lda	RelocatedVectorLow
	psha
	lda	RelocatedVectorHigh
	psha
	RTS	;JUMP to stacked vector

The above snippet is repeated for each vector you want to relocate.  The whole process is simplified a lot by using a macro.

The only 'minus' as compared to real vector redirection is the addition of the few extra cycles (~18) the above code adds.  In most applications, this is a small price to pay for this feature.

Note: I have my bootloader implemented in optimized assembly language, and it uses no interrupts for itself (e.g., SCI RX) yet it's capable of updating firmware at speeds of even 57600 bps.

I hope this helps.

[KrisRutecki]

Hello,

@Tony, very nice, instructive note. Your use of rts is  interesting and quiet cleverly avoids the issue of saving the H register...

Having said that, an addition of another byte holding the code for JMP ($CC if I remember right?) in front of the destination address makes the code a bit neater and much faster adding only 4 cycles.... resulting in the JMP table mentioned by Edward.

   I  happen to have a somewhat long interrupt happening every 5/16ms, 115kb serial communication interrupt on top of that,  another timer interrupt doing serial arbitration... Don't be surprised that I have no wish to add extra latency every time an interrupt happens - even if it is just 4 cycles.

"If the manual does not mention vector redirection... " - You are probably correct, however:  the PA60 manual is full of holes. For example it lists a register called NVM_FOPT, talking about it in quiet a few different places, without a single word about what it actually does... Any idea? Are the days of serious reference manuals over ?

I thought that maybe I missed or misread something and posted a question here.

Tony, Edward, thank you both for your effort and good intentions.

I just entered a service request asking about the IVT relocation on PA60.

[kef2]

Hi

Jump table is much faster than 18 cycles. I prefer to point bootloader vectors to application jump table entries. Single JMP instruction.

S08 vector redirection implementation is bad compared to S12X, which have IVBR register, which allows changing vectors table address at any time. Would you like vectors table not only in flash but also RAM? No problem with IVBR.

Regards,

Edward

[tonyp]

You're right that JMP table is faster (and should be used if ISR latency is very critical) but in my case I prefer consistency.

The way I do it it behaves as if redirection is always available for any MCU.  Also, my generic bootloader does not need to do any special-case loading (as compared to re-vectorable MCUs) to place the vectored pointers in their right spots.

And, I certainly agree, the 9S08 vector redirection implementation sucks.  (I have also suggested improvements several years ago but no luck.)