S08 Vector Redirection - a suggestion for improvement - GZ60/AZ60 MCUs

[Bruce_andrew]

I'm a long-time HC05/HC08 user, but only recently am I starting to use HCS08 MCUs. Have been waiting for a while (too long) for the DZ family (we use CANbus, so other S08 aren't much use).

I was looking forward to some of the new/better features in the S08, such as BDM. But the vector redirection is a huge disappointment. From doing a search, it seems that others agree that vector redirection isn't all that exciting.

We have for several years used a CAN bootloader in the GZ60/AZ60 MCUs. We use a jump table, so that the application firmware runs only if the jump table isn't all FFFF. Vector redirection *could* have been great, but it isn't. So I'm having to stick with a jump table in the DZ60.

I suppose that some people will be OK with the S08 implementation of vector redirection. Not sure what for though. Currently you have to either go without interrupts in the bootloader, or use a jump table. For it to be really useful for any bootloader/monitor code in protected flash, you really need to have control over the redirection.

On reset, NVOPT is loaded to FOPT. So redirection can be done at reset by configuring NVOPT. But FOPT isn't writeable, so you can't change it at runtime. Possibly only allow for redirection to be turned on from protected flash, to prevent rogue application firmware from "stealing" control.

My suggested "fix": make FNORED in FOPT writeable at runtime, so that 1) a protected bootloader can pass control over to application firmware (turn ON the vector redirection), 2) application firmware can turn OFF redirection, which effectively passes control back to a bootloader/monitor.

This would allow redirection on reset, as currently implemented, for applications without a bootloader/monitor. But would improve the usefulness when you need interrupts in a bootloader (eg - for CAN), AND want to then be able to swap to application firmware, with it's own set of vectors.

My question to Freescale: will new/updated S08 MCUs "fix" this problem? is Freescale happy with how it's currently implemented?

My question to other S08 users: would you like to see Freescale improve this feature? yes? no? or don't care? or does anyone have a better way to achieve this?]

Added p/n to subject.

Message Edited by NLFSJ on 2007-12-17 07:53 AM

[Bruce_andrew]

Multiple vector tables. Just 2 - the usual one, located in the last page of flash, and another in the redirected location (above protected flash).

At reset, NVOPT is loaded to FOPT, which determines which vector table is used. This gives the choice, as we have now, whether you redirect or not. Then be able to change FOPT later on, so that a bootloader can pass control, and vectors, to the application firmware.

Not being able to redirect the reset vector is OK.

The process would be:

1) start the bootloader (normal vectors)
2) bootloader decides if it should run the application firmware (check for pin state, serial message, and/or vectors != FFFF)
3)  to run the application:
         i) disable interrupts
        ii) enable vector redirection
       iii) JMP to application _Startup or main

The advantage of this is that a bootloader could use it's own set of interrupts. not at the same time, of course.

The only change in silicon is to allow the FNORED bit in FOPT to be writeable. Maybe just allow a write from 1 to 0, and then require a reset to change back to 1.

[bob_walker]

I would go one further - the normal vector table and a register that holds the pointer to the user vector table. Now add registers to control where the source of each interrupt vector comes from (normal or user). A single bit in these registers would select from one table or the other (one bit for each interrupt source). Provide the necessary protection to lock these at reset and perhaps a mechanism that would allow changing them only when the cpu interrupt mask is set.

Therefore different combinations of interrupts could be allocated to the bootloader while others would be allocated to the application.

[Nav009]

Yep!! 2 vector tables will make jumping from Boot to Application easy.

Bruce_ did you hear anything from the freescale guys.

[Bruce_andrew]

No, I've not had any constructive comments. Just the topic name being changed to to GZ60/AZ60, when the discussion is actually about S08, and specifically DZ60.

[Nav009]

Bruce_, I am also using DZ60. This is my first project using freescale. It is very frustrating to find out that we are not able to use 2 seperate vector tables (1- for bootloader and 2-Application s/w).

[K_p]

I'm also eager to hear how the redirections are realy made in simple way. I'm using S12-family, but I think basic idea in these sollutions are the same, only minor tweaking. I have been hunting information quite a while. And easiest sollution have been AllAcces-bootloader, and its so deep in there so I don't know how to rip it of there and implement it in another sollution, where I can for example use CANopen-stack or other kind of datatransfer.

Juha-Matti

[Bruce_andrew]

This thread is about ALL S08 MCUs, which is why it was titled that way. If a mod needs to add any part number to the title, then AZ60/GZ60 isn't correct, because of course they aren't S08.

I'm using the DZ60. But my question relates not to the DZ60, but ALL S08 families.

[Ake]

Hi,

I have read your message with interest, but I really do not understand what you want.

Do you want to have multiple interrupt vector tables, where you can switch from one to another, or do you want to have RAM based interrupt vector tables where its easy to change the vectors?

What I sometimes would like, is to have interrupt addresses at say 64 bytes apart, where you could write a short interrupt routine, and can skip the fetching of the interrupt vectors, but I think you would like something else. Could you explain it once more?

I guess I am just dumb not beeing able to understand what you want.

Regards,

Ake