PicKit 1 and mplab

You have two separate issues:

1. Building the code for the external RAM address range.

   This is actually very easy. All you have to do is make a linker file that contains only the address ranges you want the code to occupy. Note that you not only need to reserve a particular program memory address range for these external apps, but also some RAM space. This RAM space, like the program memory addresses, needs to be fixed and known. Simply make only those fixed and known address ranges available for use in the linker file. Don't forget to make them NOT available in the base code linker file.

   After the base code loads a new app into external memory, it has to know how to execute it. The easiest thing is probably to have execution start at the first external RAM location. This means your code will need one CODE section at that absolute start address. This contains a GOTO to the right label in the rest of the code, which will all be relocatable.

2. Linking apps to library routines in the base code.

   There is no immediately simple way to do this with the existing Microchip tools, but it's not that bad either.

   A much bigger issue is how you want to deal with base code changes. The simplistic strategy is to build your base code, run a program over the resulting map file to harvest global addresses, then have it write a import file with EQU statements for all the globally defined symbols. This import file would then be included in all app code. There is nothing to link, since the app source code essentially contains the fixed address references to the base code entry points.

   That is easy to do and will work, but consider what happens when you change the base code. Even a minor bug fix could cause all the addresses to move around, and then all existing app code would be no good and have to be rebuilt. If you never plan to provide base code updates without updating all apps, then maybe you can get away with this, but I think it is a bad idea.

   A better way is to have a defined interface area at a chosen fixed known address in the base code. There would be one GOTO for every subroutine that app code can call. These GOTOs would be placed at fixed known addresses, and the external apps would only call to those locations, which would then jump to wherever the subroutine actually ended up in that build of the base code. This costs 2 program memory words per exported subroutine and two extra cycles at run time, but I think is well worth it.

   To do this right you need to automate the process of generating the GOTOs and the resulting export file that external apps will import to get the subroutine (actually GOTO redirector) addresses. You might be able to do with with some clever usage of MPASM macros, but if I were doing this I would definitely use my preprocessor since it can write to a external file at preprocessing time. You can write a preprocessor macro so that each redirector can be defined by a single line of source code. The macro does all the nasty stuff under the hood, which is to generate the GOTO, the external reference to the actual target routine, and add the appropriate line to the export file with the known constant address of that routine, all with appropriate names. Perhaps the macro just makes a bunch of preprocessor variables with regular names (kindof like a run-time expandable array), and then the export file is written once after all the macro calls. One of the many things my preprocessor can do that MPASM macros can't is to do string manipulation to build new symbol names from other names.

   My preprocessor and a bunch of other related stuff is available for free at www.embedinc.com/pic/dload.htm.

No, you don't need to, in fact you can't, use SPI, UART, or I²C to program the PIC. The only way to get a new program into a PIC that doesn't have special code loaded for that purpose (a bootloader) is to use the external hardware programming interface. Electrically, this means connecting to Vss, MCLR, PGC, and PGD. It can be useful to have the programmer also connected to Vdd, but not necessary for this chip as long as the Vdd level is known and the programmer adjusted accordingly.

The low level hardware interface is quite simple. PGD is the data line, which is sampled by the PIC on the falling edge of PGC (the clock line). To get the PIC into programming mode in the first place, a special 32 bit key is clocked in relative to specific edges on MCLR (although see note below regarding high voltage programming).

The higher level protocol gets more complicated. Most things are done with 6 bit commands, some of which are followed by 14 bit data words. You have to read the programming spec carefully. Note that the programming spec is a separate document from the datasheet. Go to the product page for your particular PIC on the Microchip web site, and you will find a link to the programming spec in the documents section.

Added about high voltage programming

These kinds of PICs have two ways to enter programming mode, high voltage (HVP) and low voltage (LVP). The high voltage method requires raising MCLR to between 8 and 9 volts and to keep it there during programming. This method always works, regardless of any possible data programmed into the PIC.

The low voltage method of entering programming mode starts by driving MCLR high, then low, then clocking in a special 32 bit key sequence using PGC and PGD normally. The part will enter programming mode upon the correct key sequence, and will stay in programming mode as long as MCLR is held low.

The low voltage method can be disabled by one of the config bits. However, the erased state of the config bit allows low voltage programming, it is shipped from the factory that way, and this config bit can only be set to disallow LVP if programming was entered with the high voltage method. Therefore, for LVP to not be enabled, all the following have to be true:

1. The PIC was last programmed with a HVP-capable programmer, and the HVP program entry mode was used.

2. The HEX file programmed into the PIC deliberately sets the LVP bit in config word 2 to the non-erased state.

Since disabling LVP pretty much requires a deliberate action and the right programmer, it is likely still enable. If it was deliberately disabled for some strange reason, then you have to supply 8-9 V on MCLR to get the PIC into programming mode at least long enough to perform a bulk erase (which re-enables LVP).