This is merely difficult, and probably many hours of works, not certainly impossible.
This is not possible because I have many many lines of code and can not combined.
Putting 2 programs into the memory isn't impossible either, only difficult (and perhaps a lot of work, maybe, maybe not, depending on your level of skill and ability to troubleshoot tough problems). So the real question is which difficult way to choose. But since you asked for this way, here's my best attempt to answer...
First, you're going to need to make an alternate linker script, or maybe 2 or 3 others. The default one is
mk66fx1m0.ld. The important part is this line:
Code:
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1024K
This configures where the compiler will locate the code. In one program, you'll need to set "ORIGIN" to someplace not at the beginning of the flash. That will cause the compiler to create a program which can exist in the 2nd part of the memory. While not strictly required, you'll probably want to reduce the LENGTH number, so the 2 can't overlap. But that doesn't actually solve any problem, it only gives you a compiler error which is much easier to understand than "it doesn't work" (which you'll find is a theme with this way.....)
I mentioned possibly 3 files. The next problem you're likely to encounter is code in
mk20dx128.c which only works if the hardware is in a freshly reset state. Especially the startup of the crystal & PLL and configuring of clocks probably will not work if you run this code twice.
Maybe you'll make a 3rd very small program which resides at ORIGIN zero, which then runs either of the 2 others. Maybe you'll put all or most of the startup code into the 1st startup program? Or maybe you'll keep that one minimal (running from the RC oscillator, not even the crystal) and then jump to either of the other 2. Or maybe you'll decide to divvy up the mk20dx128.c code, perhaps put the hardware init stuff into the 1st program that starts and the runtime init stuff into the other 2?
Or maybe you'll go with only 2 programs, where 1 always runs first and the first thing it does is check to see if the other should be run. But even that will involve some tricky decisions about what startup stuff to do before the jump.
Making the jump to the other program will also involve some trickery. By default, the first 4 bytes are the initial stack pointer value and the next 4 are the address where the code begins. If you locate the 2nd program at 0x000020000, you can't just put the number 0x000020000 into R15 (the program counter) or otherwise jump to that address. If you use things as they are, you'll need to craft some code to read those first 8 bytes and init the SP first, then shove the next word into PC. For only a single program, the ARM hardware does this as it comes out of reset, but if you want to run another program that's built the same way, you'll need to do it.
Or maybe you'll alter the 2nd linker, or both of the others if using a 3rd small startup program, so they're in a different format where you can just jump to them more easily.
Earlier I mentioned this may or may not be more work depending on your level of skill and ability to troubleshoot tough problems with little or no feedback about what went wrong. I say this from experience of bringing up code on brand new chips... a lot of things go wrong with virtually no info other than "it didn't work". You really have to be extremely familiar with the hardware (which is *really* hard if it's a brand new chip with little in the way of working examples), but still pretty tough when you have a lot of working code to read. When you get a detail wrong like the stack pointer unaligned to 32 bits or trying to jump to an address in a way the ARM core expects one of the "unused" bits to be set to indicate Thumb execution mode, the result is a fault or hard lockup that's really hard to understand what went wrong.
In contrast, the "impossible" task of merging 2 programs with lots of conflicting symbols mostly involves compiler errors. It may seem like an insurmountable number, and many tedious hours of work may be needed to resolve them all (but cleaver use of C++ namespaces might help - again, more skill in certain areas can greatly help), but the upside is a pretty low chance of really tough-to-troubleshoot problems like getting the PLL and CPU clocking into the wrong mode where "nothing works" and you can't figure out why because the chip just ends up in a locked condition where you get pretty much no useful info.
If you're not already very familiar with most of
Joseph Yiu's book and assembly language level programming, I'd advise against attempting the linker script and startup code hacking. It may seem easier, but it's a painful path of really thorny problems.