Processor Expert and Interrupt Redirection

[RoadKill_CodeKi]

I am implementing a small boot loader in the HCS08AW60 family. The boot loader sits at the top 2K of flash, with the main code area occupying the rest. In the main application, when setting up beans for the various peripherals on the part, the beans generate interrupt vectors for those peripherals that need them. In order for this application to work properly, the interrupt vectors have to be redirected past the protected boot area into the main flash code area.

The problem is, I can't convince the Processor Expert to do this. The CPU bean allows specification of the protected area as well as setting a bit which enables this vector redirection. However, the vectors.c file that is generated by PE keeps the vectors nailed to 0xFFCC, regardless of these settings in the CPU bean. I have been unable to find other settings relating to vector redirection, other than one option that allows vector redirection into RAM, which doesn't apply here.

Any suggestions? Am I missing something?

Thanks....

[blooy]

I guess it's safe to say that once you have the PE settings in place they remain static enough to make it justifiable.

[CompilerGuru]

If I understand this setup correctly, then you have to create two applications
1- The loader. Once programmed just below 0xFFFF, it contains the reset vector and it does also enable the vector redirection. It's job is to get the rest up and running. Does not use interrupts (as the vector table is outside of the protected area).

2- The actual app. 99% of the code.

For the app, the setup in Processor expert can be done in the Bean Inspector settings for the AW60 Cpu, go to the "Build option" tab, change in the memory area 3 (InterruptVectors_ROM) the address (I used EFCC), also make the Memory Area0 (I set the size to D750 giving 0xF000 and up for the loader).
Press build, and the Processor Expert creates a Vectors.c like this:
.....
void (* const _vect[])() @0xEFCC = { /* Interrupt vector table */
Cpu_Interrupt, /* Int.no. 25 Vrti (at EFCC) Unassigned */
Cpu_Interrupt, /* Int.no. 24 Viic1 (at EFCE) Unassigned */
...

For the loader, you probably do not want a vector table at all (or more precisely, just the reset vector at 0xFFFE). I did not actually see how to switch of the generation of the vector table in Processor expert. :smileysad:
You could program a dummy, empty vector table at the right address and then just overwrite it in the loader.


Daniel

[RoadKill_CodeKi]

Partial success.

Using the CPU Bean, I was able to define a couple more memory areas, as well as convince PE to move the interrupt vector table to 0xF7CC. The one thing it did not move was the entry point (reset) vector, which is still nailed to 0xFFFE in vectors.c. Interestingly enough, the comment given for the reset vector seems to indicate that it should have moved, to wit:

void (* const _vectReset[])() @0xFFFE = { /* Interrupt vector table */
_EntryPoint /* Int.no. 25 Vreset (at F7FE) Reset vector */
};

I'm wondering if this is a bug in PE.

One other side effect of this is I have lost control of the PRM file (linker file) which specifies memory areas. Even though I specified 8 different memory areas (BOOT, ROM, DATABASE, etc), PE now dumps them all together in the PLACEMENT section of the PRM file as follows:

NAMES

END

SECTIONS
ROM = READ_ONLY 0x8000 TO 0xF7CB;
Z_RAM = READ_WRITE 0x0070 TO 0x008F;
RAM = READ_WRITE 0x0090 TO 0x086F;
InterruptVectors_ROM = READ_ONLY 0xF7CC TO 0xF7FF;
DBASE = READ_ONLY 0x0A00 TO 0x17FF;
BOOT = READ_ONLY 0xF800 TO 0xFFAF;
ROM_BUFFER = READ_ONLY 0x1860 TO 0x7FFF;
BOOT_VECTORS = READ_ONLY 0xFFCC TO 0xFFFF;
END

PLACEMENT
DEFAULT_RAM INTO RAM;
DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM,DBASE,BOOT,ROM_BUFFER,BOOT_VECTORS;
_DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM;
END

INIT _EntryPoint /* The entry point of the application. This function is generated into the CPU module. */

STACKSIZE 0x0080 /* Size of the system stack. Value can be changed on the "Build options" tab */

I am apparently not allowed to name the sections of memory I have created and use those names to separate FLASH memory areas for specific uses.

It appears that I can only redirect the interrupt vectors if I choose to redefine the memory areas and let PE generate the PRM file for the linker, however, this still has unacceptable results.

[CompilerGuru]

The split up of the reset vector from the rest is (to my limited understanding) the result of the vector redirection setting. The hardware does behave this way, so this is not a bug in PE (in my view).
You should have the vector redirection only enabled in the loader app.
If you disable the vector redirection in the main app and if you move vectors via the way described before, does this help?

Daniel

PS: I did not look into the way PE handles prm files.

[CompilerGuru]

When looking to your prm file (and ignoring PE's PLACEMENT handling), I saw that you actually defined 2 vector tables.
>InterruptVectors_ROM = READ_ONLY 0xF7CC TO 0xF7FF;
>...
>BOOT_VECTORS = READ_ONLY 0xFFCC TO 0xFFFF;

To my understanding of the interrupt redirection, this is not how it works for a HC08 AW60. The interrupt redirection is enabled in FOPT out of reset due the flash register NVOPT. Then, at runtime, the FOPT cannot be written. So all resets will use 0xFFFE and all other interrupts will use the table at 0xF7CC.

Therefore your BOOT_VECTORS from "0xFFCC TO 0xFFFD" wont be used at all.
Note that I still think that you should have two apps, and the main app should just not use/list 0xF800 TO 0xFFFF at all.
Or should the loader always be programmed together with the rest of the app? If so, them I'm on the wrong track here.

If your loader does need interrupts, then I think the builtin redirection support is not the way to go for you.
Instead map all interrupts in the loader and, once the app is up and running forward them all.

See the attachment for a sample code, stolen from the HC08 V3.1's checksum example.

[RoadKill_CodeKi]

The BOOT_VECTORS was there to prevent any executable code from being placed in that area of memory, although, when I think about it, if the vectors are always redirected, then this area just becomes spare memory, and code could possibly be placed there. The loader has no need for interrupts, so the vectors can always be redirected, which is the way the hardware is set up anyway.

I'm beginning to lean towards separating the boot code from the main code into two separate projects. It may make things a little cleaner and solve some potential problems, one of them being the sharing of internal C-library function calls, which may move from one build to the next. And PE would certainly have an easier time of it.

Thanks for your thoughts!

-Tim

[blooy]

We have the same situation. Our workaround is to freeze processor expert code generation, modify the vectors.c file, and then proceed with development, build, etc. Downside is that each time we need to regenerate the PE code we need to do the process again.

Message Edited by blooy on 03-21-200610:48 AM

[RoadKill_CodeKi]

Barring any other solution, that would be my next step. I'm wondering if the freeze/modify/build/then regenerate cycle would still be more efficient in maintaining the code than simply jettisoning the whole Processor Expert altogether and using my own code. I'm still considering that.