Program takes 23 seconds to start after 1 line code added

I've had similarly experiences when I've broken the rules for banked loads. Sometimes the load looks like it works right, sometimes it hangs, or it might run off into the weeds for 23 seconds.

The banking hardware is always in some state. That is, assuming you've got the common bank / 32K switched bank setup, there's always code in that upper 32K. It just may not be the code you need there. But if you jump to it, then it's not inconceivable that the code will do something, perhaps not immediately fatal, and even hit a RET and come back to the banked code. When you add and delete code, it's shifting the position of all the rest of the code, which may make the difference between finding a RET sooner rather than later, or falling into a loop, or whatever.

Tracing the code with an ICE would be nice if you have one.

Remember that all ISR code must be in the common bank, including functions that the ISRs call.

If you have any memory-mapped hardware or von Neumann memory, double-check the reserved areas for the linker to make sure it doesn't place code on top of the hardware, or get data in your code.

Make sure the call tree and overlay processing are correct. Don't ignore warnings here; beware of function pointers and other indirect calls.

I've never been completely successful moving string constants out of the common bank. The procedure seems easy enough, and a couple of small efforts will work, but if I move all my constants to the bank where they're needed, my load dies. There's something I'm overlooking, so I can't give you an answer, but I can warn you just in case you're relocating string constants that it might not be as simple as it appears.

I've had similarly experiences when I've broken the rules for banked loads. Sometimes the load looks like it works right, sometimes it hangs, or it might run off into the weeds for 23 seconds.

The banking hardware is always in some state. That is, assuming you've got the common bank / 32K switched bank setup, there's always code in that upper 32K. It just may not be the code you need there. But if you jump to it, then it's not inconceivable that the code will do something, perhaps not immediately fatal, and even hit a RET and come back to the banked code. When you add and delete code, it's shifting the position of all the rest of the code, which may make the difference between finding a RET sooner rather than later, or falling into a loop, or whatever.

Tracing the code with an ICE would be nice if you have one.

Remember that all ISR code must be in the common bank, including functions that the ISRs call.

If you have any memory-mapped hardware or von Neumann memory, double-check the reserved areas for the linker to make sure it doesn't place code on top of the hardware, or get data in your code.

Make sure the call tree and overlay processing are correct. Don't ignore warnings here; beware of function pointers and other indirect calls.

I've never been completely successful moving string constants out of the common bank. The procedure seems easy enough, and a couple of small efforts will work, but if I move all my constants to the bank where they're needed, my load dies. There's something I'm overlooking, so I can't give you an answer, but I can warn you just in case you're relocating string constants that it might not be as simple as it appears.

Thanks for the suggestions, I did carefully check the hardware memory mapping, so I think that is ok.

I wasn't the original author of the code, so while the ISR's are in the common block I haven't checked whether they call something outside the common block. I'll check that (Thanks!).

Thanks for the string constants warning.