How to achieve Vector Redirection when using multiple execution images?

Hi,

I am using multiple execution images in my project. And I need to use the ISRs once I switch to a different image after the first boot of the device.

Can anyone please help me out in doing this or is there any books I can refer to for this?

Regards, Ananth

--------------------------------------- Posted through

formatting link

Reply to
an_anth
Loading thread data ...

Each processor type deals with interrupt vectors in its own way. Some make it easy to change interrupt vectors, some make it hard, and some make it nearly to entirely impossible.

The first thing I suggest is that you refer to your processor's data sheet or user's manual. Find out what it says, and if you can't figure out how to get the job done with what you find, ask again in more detail.

Two examples that I can think of off the top of my head are the Cortex M3 processors and (please don't ask me why, because it's been over 20 years), the then-Motorola 68HC11.

The Cortex M3 has an interrupt vector table, and it has a pointer to that table in hardware. To change the location that the processor uses you simply change the pointer in hardware. As long as you point to the right place, you're done.

The 68HC11 has a hard-coded interrupt vector table in ROM that absolutely positively cannot be changed. If you wanted to be able to change things around in that processor you needed to make a table of jumps in RAM, point to those jumps with the hard-coded interrupt vector table, and then change the WHOLE table of jumps in RAM (and you had to use up some fairly precious RAM to do it all).

Those are at the two ends of the "easy to do" scale; you'll find everything in between, and just about every possible way to implement an interrupt vector.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Thank you Mr.Wescott.

detail.

I am using TI's MSP430 based microcontroller(MSP430F1611). And I am using CrossWorks for MSP430 as my IDE. I have understood from the Datasheet that it has a hard-coded interrupt vector table.

I need to know the details about how this is implemented. This is where I am stuck now.

This is my understanding so far:

In the ISRs I should I make a jump to the ISR of the second image. But I need to use the ISRs when I am in the first image too.

In order for this redirection to work, do I need to change anything before I make a switch from the first image to the second?

I kindly request you to be more elaborate. I have understood the concept but am lacking the knowledge to implement it.

Regards, Ananth

--------------------------------------- Posted through

formatting link

Reply to
an_anth

Make a table in RAM with enough space to hold a branch instruction for each of the live interrupts (I suspect it's 15, but I don't know -- that's for you to check, and perhaps to decide how many to support).

Point the interrupt vectors at the entries in this table.

Populate the table. If you want, you can even do this in software, dynamically. I don't think you want to, but you could.

Not knowing what all you need, I think I'd define a structure as

struct branch_struct { int branch; void (vector)(void); }

Then I'd shove the branch instruction into a const:

const int BRANCH_INSTRUCTION = ;

Then I'd define my table as

struct branch_struct[15] branch_table = { {BRANCH_INSTRUCTION, my_dac12_dma_function}, {BRANCH_INSTRUCTION, my_port2_function}, {BRANCH_INSTRUCTION, my_nmi_function}, };

Finally, I'd populate the vector table in flash with the addresses of these branch functions -- which is going to take some wrangling with the tool, which is beyond my powers (because I don't know _that_ tool) but which is, I'm sure, humanly possible if you spend enough time. Don't give up, expect it to take days, and expect yourself to go from mystified to enlightened with no warning.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

The OP has not been clear about their setup but I am assuming that there's a series of images which have been linked as standalone images and somehow combined together in flash. What follows is based on that assumption. I'm also assuming that one image's RAM usage overwrites the previous image's RAM contents due to the linker script for each image using the the same base RAM address during linking.

If that's the case, then the above RAM vector table MUST be at the same location within each image which means the vector table needs placing in it's own section and that section linked for a virtual address (VMA) at the start of RAM.

The load address (LMA) will be within the flash image and will vary by image. Note: I'm using binutils terminology here; I don't know what your toolchain calls the LMA and VMA.

Your initial startup image will also generate the actual MSP430 flash vectors to jump through that RAM table and you will probably need some way of turning off the flash vector generation for the other images.

For each image, when you run the startup code after switching to it, the startup code will copy the stored vector table from flash to RAM and for goodness sake make sure you have interrupts off during the switch _and_ reset the peripheral devices in question before re-enabling them.

I'm assuming each image is going to run it's startup code each time it's switched to, so it's probably better handled by the linker.

I wonder if a better choice might be a little assembly language routine which instead of assembling into .text, assembles into a unique section name. The entry points from the flash vectors could be in the routine and the linker would insert for correct location of the real ISR for each image. The linker script and startup code for each image should take care of the rest.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.