I've come up with another yet funny problems. Currently I'm trying to figure out how the Codewarrior linker works since it causes random crashed in the software if I try different features.
Attached to this post is a currently working PRM (not yet finished, just rough set-up). The derivative of choice is a S12G64; 64 KiB of Flash. However, if you sum up all the sections in there you will end up with approx 55 KiB.
I have deleted a section which Codewarrior did define which was 0x0C00-0x2FFF (9 KiB). The reason is that if I use this section everything crashes. Even so, in the MC9S12GRMV1 (Rev 1.23), Section 5.4.3 this section is defined as 'unimplemented' in S12G64!
So, I'm wondering where I can get my remaining 9 KiB which I'm missing?!
The S12 shall have the ability to use paged constants and variables.
Paged variables are out of question; Debugger crashes immediately (not responding); but was just a test after all (curiousity).
Moreover I tried to use paged constants, I did as the build tools reference manual described, BUT NONE of my paged constants were initialized at all; leading to total software crash (took me a while to find that out!).
So, why don't get these paged constants initialized?
I've implemented an OSEK based OS and everything runs smoothly. I explicitly tell the compiler whether the function is located in __near or __far otherwise the optimization it does goes totally wrong. So far it works unless I explicitly put functions in paged flash and mix a lot (like 5-6 layers) of unpaged and paged function calls. I tracked down the problem to the SWI instruction (this is my Yield-function, for switching the TCB).
The SWI call goes smoothly until doing the described mix up. Then it'll cause a random re-write of my Task-SP variable; so when leaving the SWI-ISR-handler it loads bulls into the Registers causing a total crash.
Though in ASM there is no pre-text happening to indicate this; I can't even see this re-write in the bus trace (though I wouldn't call this reliable as the bus trace seems to be pretty random at times). But even the CPU register does not point to that location... #pragma no_entry and the likes do not change this behavior. The assigned task stack is not a problem, I tried with up to 1 KiB but it does not even use up 96 Bytes.
An interrupt mix up should be out of question; at least I think so. The kernel task gets called periodically, disables all interrupts does some management code, enables them and does a SWI to re-load the interrupted task; takes less than 30us.
Has anyone came across the same problem or might know what I might possible be doing wrong here or where I could look into to narrow it down?
Thanks in advance for useful hints!
Original Attachment has been moved to: Project.prm.zip