memory map

[6040solder]

Hi,

I've been studying the memory layout of the hcs12c64/128 and noticed something that seems odd.

In the 2.64 gcc port, the last memory.x entry reads :

text (rx) : ORIGIN = 0xC000, LENGTH = 0x3EFF

Which only leaves space for the interrupt vector registers and NOT the bootloader, the last ms2e memory.x i checked had a last line of this :

text (rx) : ORIGIN = 0xC000, LENGTH = 0x3780

Whereas I was expecting to find length = 0x3800 therefore ending at 0xF7FF immediately before the bootloader code.

I guess my question then (purely from curiosity) is what resides in those 0x80/128 bytes?

Does the code carry a checksum of itself there?

Another question I had was what would happen if you had also mapped the paged blocks 3e and 3f? I saw another memory.x example where both paged and unpaged versions were available. Is GCC smart enough to not store data in both locations? (I doubt it) If not, was that persons memory.x broken? (maybe just lucky because their program never grew that large?)

Thanks :-)

[jsmcortina]

The space from 0xF780 to 0xF7FF is used for the relocated vector table.

Because 0xF800 up is protected by flash protection you have to employ a dummy vector table in flash that can be erased. This is standard practice and described in the Freescale monitor application note AN2548.

James

[6040solder]

Ok, thanks!

Would I be correct in saying that the initial port of 2.64 was broken in that respect?

Cheers :-)

[jsmcortina]

The downloader automatically fixes it if I remember correctly.

James

[6040solder]

Ok.

For anyone interested, heres the paragraph from the app note :

Access to the user vectors is accomplished via a jump table located within the monitor memory space. This jump table points all interrupt sources to a duplicate vector table located just below the monitor ($F780–$F7FE). The monitor will automatically redirect vector programming operations to these user vectors. The user code should therefore keep the normal (non-monitor) vector locations ($FF80–$FFFE). The monitor also checks interrupts as they occur, and it will re-enter monitor mode if execution of an interrupt with an unprogrammed vector is attempted. If this occurs, the $E3 — Stack Pointer Out of Range error will be returned. The user is strongly encouraged to implement a software response for all vectors (which is a good programming practice).

[6040solder]

I have some further questions if you have the time :

In the linker options the load to mem address is adjusted to a value that makes sense for 4 of the pages, but not the lowest two, it would appear that those lower two pages aren't being used as I describe (probably wrongly) below. I thought we were short on flash space, surely I'm missing something here. I'm guessing that the compiler/linker fills them up anyway from the low end. IE you just specify pages for things that you care are together and let it do as it pleases for the rest?

Is the number of soft registers set to 5 to save memory? (these eat into ram right?) or is there some other reason (performance?) underlying that decision?

from ms2_extra.h

#define TEXT3c_ATTR __attribute__ ((section (".text3c")))
#define POST_INTERRUPT_TEXT3d __attribute__ ((section (".text3d"))) __attribute__((interrupt))
#define FAR_TEXT38_ATTR __attribute__ ((far)) __attribute__ ((section (".text38")))
#define FAR_TEXT39_ATTR __attribute__ ((far)) __attribute__ ((section (".text39")))

appear to never be used, and compilation is successful without them present.

This one :

#define FAR_TEXT1_ATTR __attribute__ ((far)) __attribute__ ((section (".text3c")))

just appears to be a legacy line thats become in bad taste over time, ie, referring to ppage 3c as text one when its not called that anywhere anymore.

This is all from a 5th Jan beta, but quite a few of the files are polluted with ^m characters randomly. These are cleaned up by GCC no worries, but I thought you might like to know.

Thats all for now :-)

[6040solder]

While we are at it, these lines in init.c are in contradiction to the MCU specification :

// wait for clock transition to finish
for (ix = 0; ix < 60; ix++);

which specifies the following :

When PLLSEL is changed, it takes a maximum of 4 OSCCLK plus 4 PLLCLK cycles to make the transition. During the transition, all clocks freeze and CPU activity ceases.

IE, the CPU is already doing the waiting for us.

I checked back to Phil's code and it's in there too, so it's just more leftovers that you could put to better use if you need a byte or two. I guess he didn't change it and just inherited it from Al's 2.64 variant.

If it has a real purpose past a healthy dose paranoia, I'd love to hear about what it is.

Cheers.