• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 1687 views
  • Users 0 members are here
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

Problems using two programs

Andre Faure

I have created two separate programs for my AT89C51ED2: bootloader (0x0000) and normal program (0x2000). I use an absolute memory addressed variable to distinguish between the two modes of operation so that interrupts either execute code in the bootloader or call the appropriate ISRs in the program code (above 0x2000). The following is an example of the code used for interrupts in program code, in order to eliminate the usual pushes, pops and reti done by the bootloader ISR.

/** Timer 1 ISR.
	*/
void interruptTimer1(void) interrupt 3
{
	#pragma asm
	lcall interruptTimer1Mirror
	ret
	#pragma endasm
}


/** Timer 1 interrupt working function. This routine is used for delays.
	*/
void interruptTimer1Mirror()
{
	timer1Interrupted = TRUE;
}

This seems to work fine most of the time, but it seems that some of the program variables are being corrupted (idata and xdata). Is this a problem with the linker/locater not knowing about the separate bootloader program/project? Is there a better way to handle the fact that the interrupts always result in a jump to the table at 0x0000(ie. in the bootloader)?

Parents
  • 0

    Is this a problem with the linker/locater not knowing about the separate bootloader program/project?

    Could be that. Or it could be the linker not knowing about the call from that IRQ handler to the function at all --- I don't think call tree analysis looks into inline assembler blocks.

    What might work is to tell the compiler to place the interrupt table at 0x2000, even for the bootloader, and move the relevant parts of the bootloader code to a special section that gets written there iff there's no application in place, before you enable interrupts.

Reply
  • 0

    Is this a problem with the linker/locater not knowing about the separate bootloader program/project?

    Could be that. Or it could be the linker not knowing about the call from that IRQ handler to the function at all --- I don't think call tree analysis looks into inline assembler blocks.

    What might work is to tell the compiler to place the interrupt table at 0x2000, even for the bootloader, and move the relevant parts of the bootloader code to a special section that gets written there iff there's no application in place, before you enable interrupts.

Children
  • 0 in reply to HansBernhard Broeker

    I have successfully accomplished the exact thing that you desire. The trick is to actually use 3 programs.

    The first contains the interrupt vectors located at address 0. All interrupts are handled. Each interrupt handler interrogates a specific bit (I either use F0 or 20^0) to determine whether the interrupt is for the BootLoader or the real application. It then jumps to the corresponding interrupt +0x200 if in the bootloader or +0x2000 if in the application.

    The normal startup at location 0 points to startup code in the BootLoader (Program at address 0x200). The bootloader sets the "BootLoader" flag, determines whether the application is loaded (via checksum info saved in an unused interrupt vector address) and if so, clears the "BootLoader" flag and jumps to address 0x2000. If the application is not loaded it simply waits to do the download. When I load the bootloader initially, I merge the hex for the interrupt vector program with the bootloader hex to create a valid operating program.

    The application has it's interrupt vector set to 0x2000. The startup code is modified to ORG at 0x2000 also. Other than that, the app is just a normal program.

  • 0 in reply to Bob Horeck

    Thanks for the advice. I'll give it a try...