Here is the work around. I tested it with 2 of the projects.
}
#pragma section CopyToRAM end
BTW: This fixed applies to projects that execute from the FLASH.
Just following up - we do pay attention! In the abence of any specifics, we tested them all and haven't been able to replicate the problem, running in both RAM and flash. We're still trying to nail down if this is a replicatable problem, but so far, have not been successful duplicating this.
We genuinely appreciate reports like this. THis is why forums are so cool - if there are problems, you help us find them. Even if it turns out to be a false alarm, that's OK. Sometimes that smell of smoke turns out to be a real fire. It definitely pays to check.
Sorry Jim, I just saw this.
I noticed that the exmaple programs now seem to have a __relocate_code__ macro to handle e2448.
Let me check everything again.
Its wierd, not all chips exhibit e2448.....
Jim:
Also could you have your apps guy look into the linker files? Here is the issue:
in the KINETIS_SC examples, there are a bunch of linker files for the example code. But these linker files are alot different from the ones used when you create a "bare bones" project in code warrior, often making code porting difficult if the have to work around e2448.
For example compare the 256KB_flash.lcf in the samples to what codewarrior by default generates. Alot of the exmaple code needs the .relocate_code section but the default codewarrior linker file does not have this. It would nice if these were all in agreement.
Can you identify which particular examples you had the problem with? I'll point them out to the apps team and we'll test them and fix them if required. I sit about 50 meters from the apps manager. These were all tested on the CodeWarrior MCU 10.1 tools, so this should not be an issue. But... let's see what's happening.