PPAGE in MC9S12A256

[satya]

Hi,

First time I'm using Freescale MC9S12A256 16bit controller. It is using paging concept to access 256KByte inbuilt Flash with 16K address space and PPAGE register. My application code is more than 64KByte, stored in block 2 & 3 of inbuilt Flash and it is executing from FLASH(using page window). Because it is >64K, it is not only crossed the page boundry but also block. Let us assume that current executing instruction was at the end of the page 2 of block 2 and next instruction to be execute was at the begining of page 3 of same block.

Question:

Is it PPAGE value will automatically update from $36 to $37?

If it is so, which part of the controller will do it?

Is any reference document covered this point?

Here i'm not performing any jump or call instructions. It may be some critical application code.

[CrasyCat]

Hello

I assume you are using CodeWarrior for HC12 V4.5.

Am I right?

If this is the case you do not have to care about that. The linker will never allocate an object (function, variable, constant) over a page boundary.

So a function will always be implemented on one single page.

CrasyCat

[satya]

Hi,

Thanks for your rsponce.

If this is the case, some times, linker may not be utilise 16k page effectively.

Actually, we are planning to use GNU tools as developing environment, not CodeWarrior.

Whether GNU tools will take care of it? If not how we can handle this.

In my application, at run time, I have to download new version aplication image and program it in other free pages in Flash without effecting the running application. My application size will be between 80-90KB.

So i'm planning to use

Block 0: for Bootloader, Flash drivers and other service routines. (non-banked pages)

Block 1 & pages 0 &1 of Block 3: for Application image1. (total 6 pages)

Block 2 & pages 2& 3 of Block 3: for application image2. (total 6 pages)

To achive this what precautions I have to take?

How can I handle page boundries at run time programing?

[mke_et]

I'm using an 'A128' part and I'm using just about the whole thing. Actually, I'm using every page, but I do have some room on some of the pages.

While the way I did it may not be fully applicable to your situation, you may be able to get some tips.

First off, think of what you need to do, and keep in mind the operational anomolies of the flash.

Remember that the memory at C000 will always be there at C000 (but can also 'map in' to the page area at 8000).

Remember that you can have a second 'always there' area at 4000 (but it also can 'map in' to the page area).

And remember that programming any of the flash pages means that certain other pages in the same 'bank' as what you are programming are not accessable while programming operations are taking place. You can get around this by either having two copies of certain programming code, each in a different bank, or write your code so that it copies itself to RAM and executes.

Ok, you have 2 pages you can always get at in normal operations with a 3rd 'switched in' depending on what you need to do. Make sure all your 'common code' is in the 'always there' area, and only use the 'moveable bank' for stuff that is temporary. That's 48K, but it may still not be near enough. (I personally needed ALL of a 128K part, although one bank is used strictly as data.)

What I did in my code was broke up my program into 'modules' that were each independant of one another. It wasn't really that hard for me, since I originally had 3 separate products that ran on the same or similar hardware, and in conversion went to a single common platform. I found myself ripping out code to be in a 'common' area. Then I wrote a 'page scanner' as part of my boot process. This page scanner just walked all the pages looking for an ID header block that defined what was on the page and entry points. These would be added to a menulist on the main program area and the user now can select any of these items from a list on the display.

In cases where I have code that needs to access more than one switcable page, I just had to write a small snippet that sat in the common area to manage page swaps so as to not let anything collide.

One thing to be very careful of... Be aware of what is needed by any of the ISRs!! It's pretty obvious that you have to have the ISRs in memory that won't switch out, but you also have to make sure that NOTHING that is referenced in an ISR is switchable as well! If you have to, you will have to change your ISR to a 'dispatcher' type routine that just sets something up for later and let the 'page switch' routine handle it when what is needed is back in place.

Finally, make sure that any flash operations that could make the bank where the ISRs appear go invisible set up things so that an interrupt can't happen! Big time burn if you forget that!

Mike