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

Code Loader Issues

All,
We are designing a "loader" for field firmware updates. Unfortunately we do not have the code space (P89C668) to have two sets of code in on-chip flash. Therefore we will use a scheme where we have the loader code located in sector one and all the ISRs in sector zero as the loader will use interrupts. The rest of the application will be in sectors 2 and up.

The loader will erase the upper sectors and program the new code there. It will then erase sector zero and reprogram the vector table and the ISRs. Block one, the loader, will remain unchanged.

Questions:
I think I can locate the code in sector one and the ISRs in sector zero using user classes. I have done this with some ARM code in uVision. How can I be sure that the loader will have all the run-time modules it needs in sector zero? In other words, I cannot have the loader calling code in sectors that have been erased. It will have to be completely self contained except for the ISRs.

Is this a reasonable plan? Anyone have a better way to do this?

Rich

Parents
  • We have the same problem in a number of products. Our solution is to put the boot loader and the interrupt vectors in the first part of memory ... in our case the first 4k.

    We have the application start at 0x1000, while the Boot starts at 0x100, the interrupt vector processing is the only code at 0. Do this by relocating the interrupt vectors (see C51 TAB in uVision) and changing the StartUp.A51. We reserve an unused interrupt vector block in the application to keep a checksum that is generated by the Boot after successful download.

    The actual interrupt code uses the same scheme that RTX uses ... ie. we set a bit (RTX uses F0) to indicate that we are in the boot. If an interrupt occurs while in the boot, we use an AJMP to 0x103 + (8*Int#). If an application interrupt occurs we do a LJMP to 0x1003 + (8*Int#). The two jumps and the JNB InBootBit all fit in the standard 8 byte interrupt vector slot.

    When the processor is reset, the Boot executes first and jumps to 0x1000 if the application checksum is valid. If not it simply waits for download.

    In this manner, the boot is really simple and handles the TxEnable and any other special stuff.

Reply
  • We have the same problem in a number of products. Our solution is to put the boot loader and the interrupt vectors in the first part of memory ... in our case the first 4k.

    We have the application start at 0x1000, while the Boot starts at 0x100, the interrupt vector processing is the only code at 0. Do this by relocating the interrupt vectors (see C51 TAB in uVision) and changing the StartUp.A51. We reserve an unused interrupt vector block in the application to keep a checksum that is generated by the Boot after successful download.

    The actual interrupt code uses the same scheme that RTX uses ... ie. we set a bit (RTX uses F0) to indicate that we are in the boot. If an interrupt occurs while in the boot, we use an AJMP to 0x103 + (8*Int#). If an application interrupt occurs we do a LJMP to 0x1003 + (8*Int#). The two jumps and the JNB InBootBit all fit in the standard 8 byte interrupt vector slot.

    When the processor is reset, the Boot executes first and jumps to 0x1000 if the application checksum is valid. If not it simply waits for download.

    In this manner, the boot is really simple and handles the TxEnable and any other special stuff.

Children
No data