Hi Sebastian, I got in contact with the CW developers and indeed there is a compatibility problem. I'm posting their answer below... Have a nice day, Allem77. From Dev team: ************************ There is a compatibility problem (though not documented). With MemoryBanker enabled, a few peculiar header files (either provided with the library or linker-generated) need to be automatically included via the -AddIncl compiler option. Given the example you provided (test.mcp), this is what the compiler command line looks like: - for target 'Pass1': -CpuHCS12XE -Ml -D__NO_FLOAT__ -MapFLASH -D__MAP_FLASH__ -AddIncldistribution_support.h -MemBanker -D_DISTRIBUTE_CODE -D_DISTRIBUTE_CONST -D_DISTRIBUTE_DATA - for target 'Standard': -CpuHCS12XE -Ml -D__NO_FLOAT__ -MapFLASH -D__MAP_FLASH__ -AddIncl__MB_code.h -AddIncl__MB_data.h File distribution_support.h is provided with the HC(S)12 library. It contains the CODE_SEG/DATA_SEG pragmas required for activating code/data distribution. If it were not automatically included, it would have to be explicitly included in each source file within the application (obviously, only for the first compile-link pass). Files __MB_code.h and __MB_data.h are generated by the linker during the first pass. They contain the code/data distribution optimization information (provided via CODE_SEG/DATA_SEG pragmas) that the compiler needs to use in the second pass. As with distribution_support.h, if these files were not automatically included, they would have to be included in each source file (obviously, only for the second compile-link pass). When PRM file preprocessing is enabled, the compiler-embedded preprocessor will be instructed to preprocess the PRM file as if it were a C source file. The linker will then use (as linker parameter file) the preprocessing output (i.e. .pre.prm, not .prm). On the other hand, the -AddIncl options (for including the above-mentioned header files) directly affect the compiler-embedded preprocessor: it will include the header files prior to preprocessing the PRM file, just like it would do for any other source file to be preprocessed. Therefore, CODE_SEG and DATA_SEG pragmas will make it into the PRM preprocessor output - that the linker will subsequently use. The linker cannot handle CODE_SEG and DATA_SEG pragmas, hence the problem.