interupt vector flash address: MSP430g2553

Maybe you're thinking of the MSP430s with CPUX extensions supporting 20 bit addressing. I think those require the interrupt service routines to be placed within the first 64kb, as the interrupt vector table entries are still only 16 bit.

The interrupt vectors are near 0xFFFF. They point to the ISRs located elsewhere, which are usually static as assigned by the linker.

Combining and extending both answers:

Directly below the 64k ‘border’ is the interrupt vector table. It ranges from 0xFFFF down to 0xFF80 or so (depends on MSP family).

So, since the MSP430g2553 has only 16K of flash, is it correct to say that the ISRs are just placed with regular code? 

In my particular example, I block off memory from 0xC000 to 0xDC00.  I modified the linker file thus:

-Z (CODE) CSTART,ISR_CODE,CODE_ID = DC04-FFDF
-P(CODE)CODE=DC04-FFDF

So I think that I took care of moving the ISR code myself.  However, what I'm not clear on is whether or not this was all I had to do to move the ISR code.  In other words, did I correctly block off memory for data without accidentally stealing memory that is supposed to be protected for other things?

Mike

The change to the linker command file looks OK by me, the linker will not place code before 0xDC04.

However, I would like to as a control question. Why do you reserve this manually? The linker will allocate all data and code you have in your application into suitable locations in memory. By splitting the memory range you could end up with having too little space in one part at the same time as you haven't used up all space in the other part.

    -- Anders Lindgren, IAR Systems

the data is stored in flash as it comes in.  We are storing a few values from the ADC, but exactly how many we need to store each run is not specified, up to a maximum (I think i allocated 7000 bytes or something like that as a max).  So we block off the memory, erase it, and use it to store the data during the experiment, then download that data afterwards.  Is there a non-manual way to do that?  I can imagine something like this:

1) write your code to flash

2) Find (somehow?) the memory range that is not filled with code, since I assume and hope that code is contiguous in memory

3) use from that space to some max. value, probably where the interrupts live.

Is that easier?

There are a number of ways you can do this, without rewriting the linker command file.

One is to simply define a large C array. You might need to increase the alignment of it so that you safely can erase the flash it is stored in.

Another would be to use the built-in intrinsic function __segment_end() to find out the end of the topmost allocated segment, and place your date above it.

Of course, your original solution is sound -- I just wanted to make sure that you didn't assumed that you had to edit the linker command file manually.

    -- Anders Lindgren, IAR Systems

Ah, in fact I did assume that you had to manually edit the file.  I think the array is easier, though.  I wonder: I'm currently having an issue writing some data to my flash addresses.  If I had allocated a large array, would my flash write issues be reduced?  To that end, if I do allocate a large array in flash, wouldn't I only be able to write to a particular location once, and then have to erase the entire segment before re-writing?

Yes, the normal flash write rules still apply. Using an array is simply a more convenient way, comparing editing the linker command file.

The simplest and hassle-free way to reserve a storage area is to declare a const array that is 512 bytes larger than the need area. The linker places it somewhere, but due to the oversize, it is ensured that  it will cover an area that is large enough and aligned to flash segment boundaries. You can then take the pointer to this array, add 512 and clear the lower 9 bits and you’ll have a pointer to your storage area.

This method is 100% portable and survives updates of the linker file due to new compiler revisions. It does, however, waste 512 bytes of flash.