Vector Redirection in HCS08

[bob_walker]

Has anyone designed a bootloader that uses NO INTERRUPTS,  that resides in high memory and uses both Flash Protection and Vector Redirection for the application?

To be more specific - the application executes interrupt services that are VECTORED automatically via the RELOCATED vector table in the application space  and NOT via the use of a re-vectoring (i.e. software) table residing in the bootloader...

My bootloader ( @0xFC00-->0xFFFF) is verified working. The first instruction executed in the bootloader is SEI.

Interrupts are NEVER enabled in the bootloader. The correct and verified application vector is jumped to (PC=application startup vector). The application vector table residing at 0xFBC4 (9s08JM60)  has verified vectors pointing to their respective handlers.

My question is - Does the HARDWARE vectoring actually work or is it vaporware (bugs?) on behalf of Freescale?

[ok2ucx · Accepted solution]

Bob,

to answer your original question - yes, such S08 bootloader has been developed, exists and uses all features you refer to. It is described in AN2295 Freescale Application Note. The part of Flash´(with bootloader) is protected from the very first instruction, thus bootloader resides safely in memory. No regular way how to modify (erase) this part of the memory.

Interrupt vector redirection is turned on (where available), the user code interrupts reside at the very top of unprotected memory. In addition to this, the user code can make protection barrier lower (i.e. protecting more memory) by writing to FPROT register. The protection remains active till next reset. Interrupt vectors however remain at the original location (as specified by NVPROT register) - this behaviour is not explicitly mentioned in the datasheet though.

Hope this helps,

regards,

Pavel Lajšner

Freescale Czech

Application Engineering

[bigmac]

Hello Bob,

No, it is not possible to provide flash protection for the application code.  Firstly, with such protection enabled, you would be defeating the purpose of using a bootloader, since flash erase and re-programming would be inhibited, using the bootloader.  Secondly, automatic vector redirection will not work since the application vector table needs to reside at an unprotected flash location immediately below the protected flash area (for the bootloader code).

For the application vector table to reside at 0xFBC4 to 0xFBFD, the highest unprotected flash address should be 0xFBFF, to obtain the correct vector redirection offset.  This would imply that NVPROT register should be programmed with a value of 0xFA.  In addition, the NVOPT_FNORED bit would also need to be programmed to zero (when the bootloader code is programmed)

Regards,

Mac

[bob_walker]

Mac,

I concur with you - protecting areas of flash will make it impossible to update the protected flash without the use of a BDM cable - which means the bootloader must NOT be protected if you plan on field updating later on....

which means that vector redirection is not possible due the fact that it's tied in directly with the protect mechanism... which means that the use of software vector redirection is a must....which means that this is a major Freescale FAIL!

Had they decoupled the vector redirection from the protect mechanism we could have had a bootloader that utilizes only the reset vector and an application that could utilize the rest of the vectors - re-located to another address boundary (outside of the protected flash).

So we're left with the ability to SECURE the flash and update it (with the use of the backdoor key mechanism).

[kef]

I like how it is done on fresh S12(X) parts.

1) There's IVBR (interrupt vectors base register), which defines where CPU should take interrupt vectors from. Unfortunately there's no write protection mechanism for IVBR, but it is still much better then what you have in S08.

2) Flash protection register on S12 is writeable from user software. Initial FPROT value is taken from location in flash. User software can write directly to FPROT register. There's built in logic, which doesn't allow to unprotect already protected flash. It is possible to write protect more flash, but you can't unprotect any piece of flash. It is great compared to S08, on which you have to either keep app. code never write protected, or can write protect everything just once, writing to NVPROT.

[bob_walker]

Edward,

You are correct - you can only ADD to the already protected memory. The ability to un-protect memory is a major fail, in my mind. User code should be able to protect/unprotect flash sectors as needed. A bootloader is a real-world example - field upgrading is not possible if it is protected. Freescale needs to rethink the HCS08 secure/protect schemes. I, personally, would like to have the ability to protect/unprotect individual flash sectors, have a vector base register for remapping the interrupt vectors, and have the ability to select which vectors are remapped (individual remap bit for each irq), As far as securing the chip, the current scheme with the back door mechanism is good. Perhaps this scheme could be modified to include protect/unprotect. The actual hardware added to the chip would be very minimum.

[bigmac]

Hello Bob,

Firstly, I cannot see why you would need to update the bootloader code without using the BDM.  The bootloader should be well proven code whose limited functionality is unlikely to change over time.  With the potential risk of "losing everything" following either a mass erase, or after the highest page, including the vector table, is erased, IMHO this process should not be carried out by, for example, your customer.

Even so, if you do persist with the concept, for something that is not normally required of the MCU, the work-around solution is relatively simple.  Rather than using automatic vector redirection, you can provide the vector redirection process for each vector from within your bootloader code.  The vector redirection then is not connected with the flash protection range.  My estimation of the additional code requirement is about 11 bytes per vector.

Regards,

Mac

[michaelbodnar]

Code density is only one concern here; if I understand your suggestion, there's extra latency incurred by doing the redirection in software.

Every time a vector is fired, it will first check if its in boot or app mode.  If in app mode, it redirects to the app's vector table (outside protected space), and then finally invokes the app ISR.

This seems a viable solution, if the application can tolerate the extra latency.

What have folks found with this technique?

[rocco]

Hi Bob,

Bob Walker wrote:

. . . field upgrading is not possible if it is protected.

There is a way, but it's a little ugly, and it only works if you have enough ram.

Since you can do a mass-erase from firmware, the entire flash can be erased if the entire "bootloader's bootloader" is loaded and run from ram. I update my bootloader by updating the normal firmware with bootloader-update firmware that, when it runs, moves itself to ram, mass-erases flash, and then programs the new bootloader. But it's only feasible because I have 4k of ram. With less ram, I would probably move just the main update program and an SCI driver to ram, and send the new boot-code, and possibly overlays, through the serial port. This can accommodate a larger bootloader.

The downside of this approach is that, if your not careful, the update procedure can brick your mcu. Fortunately, I can un-brick them with a BDM, if it is sent back to me. I haven't had that problem yet, as I've haven't needed to update a bootloader in the field.

[bob_walker]

True. That would work. In fact that was the implementation that I decided to use for updating my bootloader - running a version that ran out of ram. I hadn't thought of mass erasing the flash though. My bootloader is 2K so ram isn't a problem. Good idea Mark. Thanks for that.

[bob_walker]

Mac,

My wording was a bit ambiguous....I didn't mean to say that the application is flash protected - only the bootloader.

I understand how it all works - except IT DOESN'T WORK. I have everything set up just the way you have outlined it.

So my question remains - Has anyone designed a bootloader that uses NO INTERRUPTS,  that resides in high memory and uses both Flash Protection (for the bootloader) and Vector Redirection for the application?