• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 21 subscribers
  • Views 788 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

A question about ISRs, bootcode and application code

Catcus Blip

Hello all,
Why is it that the boot code and the application code cannot share the same ISRs? I had a look at previously posted threads in the forum but I couldn't find a technical explanation. Can you?
Thanks in advance,
CactusBlip

  • 0

    For starters: because it must be possible to change the boot loader and the application independently from each other --- otherwise there would be no point making them separate entities.

    A boot loader can't know beforehand what the application might need to do in which interrupt service handler. The application cannot generally restrict itself to those (few) ISRs the boot loader may use.

    This offers two main possibilities:

    1) to redirect interrupt invocations either into the boot loader or into the application, depending on which of them is running.

    2) A boot loader that uses no interrupts at all

  • 0 in reply to HansBernhard Broeker

    Just add another possibility that is available on the XC16x devices (and others) concerns the ability to change the base address of the interrupt vector table (via a SFR). This allows for a completely independent vector table between the two code sets, application and boot. It still requires the boot code to change the entry before running the application code and serves to reduce the interrupt latency of running shared code in the ISR or implementing a double jump table.