Bootloader, program will not run when #ORG is changed

[Ttelmah]

For a PIC18, there are _two_ interrupt entry points. One for the low priority handler, and one for the high priority one. jump_to_isr, automatically generates both.

No the #build _does not_ 'place code to re-vector interrupts'. It tells the code 'where' to put it's boot, and interrupt code. Jump_to_isr, then generates the code to re-vector to the same point.

You have to deal with the difference between byte addresses and instruction addresses. The (LOADER_END + 5 * (getenv ("BITS_PER_INSTRUCTION") / 8));, says to jump to five _instructions_ after the LOADER_END. Loader end is the instruction before where the build will place the code.

Yes you can amend the code to write the EEPROM. You would need to look for the addresses in the EEPROM address range, and then subtract the address of the EEPROM start from these, and use write_eeprom to write the data. Quite fiddly. Normally people wouldn't bother, instead write default values to the variables in the code, then test the EEPROM for a checksum, and if it is invalid, write the values from the variables into the EEPROM, and reprogram the checksum. This way the default values will be restored if there is an error in the EEPROM.
Problem is that you (as a bootloader), are not actually a 'device programmer', and so the assumptions in the hardware made when writing the hex directly, do not apply. Different code needed to write the EEPROM from code.

[russk2txb]

Of course you are correct. I was just being a bit overwhelmed at all of the problems I am having, both with this hobby program and with my day job programs. Forgot that I had not posted in the current thread. I will endeavor to do better next time!

Thanks

[russk2txb]

Jay and Ttelmah,
Thanks for all your help in understanding how to make this work. I now have it doing most all of what I want. I added code to write to the eeprom and that works well. The last round of problems I had seems to be due to the serial port (USB) on my computer getting screwed up. It was actually swallowing all binary zeros that were sent from the controller to the PC. I figured it was some problem caused by relocating the program but that was not the case. Resetting the USB dongle cured the problem.

Next I loaded the boot loader and then used it to load the program. Then I used CCSLoad to read back the contents of the rom into a file. Now that file can be uploaded using ICD to load the program and the boot loader at the same time - works like a charm.

Next I want to fix my program that sends the hex file so it can invoke the boot loader when it has already been used, instead of using a push button. I figure I can just tell it to GOTO the address of the boot loader main. haven't tried it as yet.

Thanks again,
Russ