I upgraded uVision (from MDK-ARM v3.22 to 3.4) recently. After I tried to compile my project from previous version I noticed that the HEX file became a lot larger than before.
Before, the whole code was put into LR_1 section, but now it is separated in ER_IROM1 and ER_IROM2. ER_IROM2 begins exactly 16kB after end of ER_IROM1 and I found no way to persuade linker to put these section together.
For the moment, my project does not support HEX files as large as this, so I want to get rid of this 16kB useless space that is put in the code.
Lastly, even if I try to load the entire HEX file into my LPC2364, the code does not run as it should.
You have to downgrade back to the previous evaluation version. Keil has added 16kB of blank noise just to make it harder for anyone to use the evaluation version for commercial projects.
At the same time, they managed to get the evaluation version to fail building at least some of the demo applications that the previous eval version could build. Hopefully, this has already been corrected, but I haven't seen any note to that fact.
See: http://www.keil.com/demo/limits.asp
specifically, the last bullet point:
The vector table, reset handler, and library initialization code are linked at the base address. The remaining user code and constants are offset from the base address by 0x4000 (16 KBytes). Programs generated with the Evaluation Version of the tools may not be programmed into single-chip devices with less than 16 KBytes of on-chip ROM/Flash.
It seems that Keil are being a bit misleading about this: it seems that this 16K offset is counted as part of the 32K limit - so that the evaluation version can really only build 16K of real project code?
One more reason to start using GCC...
"It seems that Keil are being a bit misleading about this"
Yes, it is this little party trick that makes the evaluation version fail to build examples that was possible to build before this little "improvement".