S12G - FLASH partitioning

Discussion created by puppetmaster on Jun 24, 2013



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?!


Second problem:

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?


Third problem:


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!

   Kind regards,

Original Attachment has been moved to: Project.prm.zip