Memory mapping MC9S12NE64

[Wind]

hi,

I am using MC9S12NE64.

I am quite confuse with the flash EEPROM mapping. In the MCU address range, the flash is from $4000 - $FFFF whic is only 48K. shouldn't it be 64K flash?

MCU address range

$4000-$7FFF                      unpage $3E

$8000-$BFFF                     $3C, $3D, $3E, $3F

$C000-$FFFF                     unpage $3F

what does it mean by unpage (or non bank), and it seems like the unpage $3E and unpage $3F are sharing the memory location with $3E and $3F of memory$8000 - $BFFF

what is the block relative address?

For the block relative address from $0000-$FFFF ( $3C, $3D, $3E, $3F) = 64K.

but this 64K block relative address is within the MCU address range of 16K ($8000-$BFFF ). I am really confuse.

regards

[mjbcswitzerland]

Hi Wind

I use the NE64 with 100M LAN, where external memory is not possible. When I started with the NE64 it was using the GNU compiler which is not very efficient when paging is involved and so I decided to avoid it - this is how:
1. If you leave the PPAGE as it is after reset, you can address 0x4000...0xffff continuously (48k) which gives maximum efficiency.
2. The 16k 0x3d page (0x3d-8000..bfff) is then used as a file system. I down load web sides via FTP to this block with interface read and write routines which get and put data to the page.

I find this works well because when doing embedded IP applications a file system is really needed and 16k is a suitable size for about 5 controle web pages or for saving some recorded data and such. The code remains optimally efficient because there are no 'trampoline' functions.

Of course this limits the code size to 48k and there is 16k less than would otherwise be available (assuming no file system, if this makes sense). However the overhead for the trampoline stuff improves the figure somewhat. Then the compiler is also not to be ignored. If I take a 64k sized code compiled with the GNU compiler and compile it with IAR (I believe Codewarrior figures are similar) the code becomes about 40k in size and so fits after all.

If you have code which is larger that 48k then of course this will not work. Then paging will help - in which case I have a solution to access the file system in SPI EEPROM. If the code is larger that 64k then external memory will be necessary - which I avoid (first I don't want to sacrifice 100M LAN and secondly I use the 80 pin device with no ext. bus since it is rather smaller).

When bigger codes are involved I move to other devices like the Coldfire MCF5223x (although it is not yet really available - but it is a Freescale forum and I don't like to mention AxxxL). Interestingly, these Coldfire devices are more or less pin-out compatible to the NE64 and will not be much more expensive if the first indications are correct. Then there are also no paging difficulties to be faced...

Regards

Mark Butcher
www.mjbc.ch

[Wind]

hi,

if

initrg = 0x30;

initrm = 0x00;

initee = 0x39;

register  address will be $3000 to $33ff (if 1 K register)

RAM       address will be $0000 to $1FFF ( consider 8 K RAM)

EEPROM    address will be $3800 to $3FFF ( consider 2K EEPROM)

the register,RAM and EEPROM  are mapping to the MCU memory address : $0000 to $ 3FFF. This address range ($0000 to $3FFF) is different with page 3C ( block relative address $0000 to $3FFF). Thus I still have 64K flash.

Mark,

why didn't you put your ftp files in page 3C? any reason? or you just happen to choose page 3D to store your ftp file. ?

if now

initrg = $0x00  (  2 K, REG_SW0=1)

initrm = $0x18  (16K, ram_sw2=1  ram_sw1=1  ram_sw0=1)

intee  = $0x09  (4k, eep_sw1= 1 eep_sw0=0)

register  address      : $0000 to $ 07FF 

EEPROM address    : $0800 to $ 17FF 

RAM address             : $1800 to $ 57FF (16K)

Now I am mapping RAM to 'MCU address of $57FF and this is part of the unpage 3E. If memory blocks are mapped to the same address,The priority is Register, RAM, EEPROM and Flash ROM. and thus I am loosing some flash memory of $3E.

please correct me if I am wrong.

MCU AddressRange            PPAGE                    Block Relative Address1

$4000-$7FFF                        Unpaged                        $8000-$BFFF

(16K)                                          $3E

---

$8000-$BFFF                             $3C                           $0000-$3FFF

(16K)                                           $3D                           $4000-$7FFF

                                                   $3E                           $8000-$BFFF

                                                    $3F                           $C000-$FFFF

---

$C000-$FFFF                        Unpaged                         $C000-$FFFF

(16K)                                         ($3F)

my reference:  EB386.pdf

regards

[mjbcswitzerland]

Hi Wind
I wish you had asked me a year ago because I would probably have been able to give you the exact answer.
I remember experimenting with the debugger to see what worked best and went for the 0x3d page. Whether the 0x3c or 0x3d page is selected probably doesn't make any real difference because in both cases the 16k which I wanted to access outside of the linear 48k can be addressed between 0x8000..0xbfff.

At the end of the day I have some user routines which can be called to maniputale data in this address range, whereby the user doesn't actually have to know where it is.

The file system calls do work with a pointer to the physical address (when the page is switch in), which is actually in the range 0x8400..0xbfff since I reserve 1k at the beginning for parameters such as MAC address, etc.

The uTasker supports the following file system calls, which are also used by FTP, HTTP etc.:

extern unsigned char *uOpenFile(signed char *ptrfileName);

extern MAX_FILE_LENGTH uGetFileLength(signed char *ptrfileName);

extern MAX_FILE_LENGTH uGetFileData(signed char *ptrFile, MAX_FILE_LENGTH FileOffset, unsigned char *ucData, MAX_FILE_LENGTH DataLength);

extern MAX_FILE_LENGTH uFileWrite(signed char *ptrFile, unsigned char *ptrData, MAX_FILE_LENGTH DataLength);

extern int uFileClose(signed char *ptrFile);

I can't comment with detail on the other points since I never tried moving RAM and registers around, simply for the reason that I don't see the point when using the NE64 in single chip mode - especially as you point out, which may well be the case - that you loose FLASH access when doing so. I see no advantage in loosing FLASH and so am happy with the simple set up

Regs. 0..0x7ff
SRAM 0x2000..0x3fff 8k
FLASH 0x4000..0xffff 48k
"paged" File system 0x8000..0xbfff 16k

Regards

Mark Butcher
www.mjbc.ch

[Wind]

hi,

In the MC9S12NE64 spec it is written 8K onchip RAM available but in the registers MEMSIZ0 (ram_sw0, ram_sw1,ram_sw2) I can choose my RAM for 2k ,4K 6K,10K, 12k ,14K or 16K.

does this means that I can have my onchip RAM up to 16K and this is done so by replacing some of the flash ROM memory?  

or

I can only use up to 8K RAM, the rest is just reserve?

regards

[mjbcswitzerland]

Hi Wind

The register which you refer to reflects the chip´s configuration. Its contents are predefined for the specific part and can not be written to.

Of course the NE64 has predefined amounts of memory types which can not be swapped around.

These registers are probably only of use if you have a software version which can run on seveal different types iof HC12 and must check to see what resources are available when starting. Otherwise they have no other real function.

Regards

Mark Butcher

www.mjbc.ch

[Wind]

hi mark,

thanks. I understand now.

my mistake, the MEMSIZ0 is a read only register.

regards

[EMontanez]

Mark is correct. The newly introduced ColdFire MCF5223x Family creates an upgrade patch from the MC9S12NE64 which is pin similar (BDM interface is different, plus you have full UARTs accessible).

Plus, you have a linear addressing space (no paging necessary) and up to 256K internal flash. See thread below for more information:

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=55

[imajeff]

K, you might not like this, but the memory banks are what makes it 64K, and they are not contiguous.

To think about it, if all 64K of the 16-bit memory space were Flash, there would be no space for RAM and hardware registers (let alone any possible expanded i/o). The 16-bit address is an architectural limit, meaning no instructions could address a single address space other than the 64K bytes that I will call "near".

Seeing why they are called PPAGE is real simple. The space $8000-$BFFF is a "page window" or bank window intened to turn through all the pages of Flash memory. A hardware register called PPAGE chooses which program page is visible in that window. There are actually a few newer instructions aware of PPAGE so when you want it to jump to a subroutine in the far address 3D:8010, it will automatically write $3D to PPAGE, then JSR $8010.

Looking at

MCU address range
$4000-$7FFF unpage $3E
$8000-$BFFF $3C, $3D, $3E, $3F
$C000-$FFFF unpage $3F

Notice that you can access "fixed" pages faster because you don't have to change PPAGE (always near). In the NE64, `LDA $C000` would get the same memory location as `MOVB $3F,PPAGE` `LDA $8000`.

So a fixed (or unpaged) window is another near address space that always sees one Flash bank and ignores PPAGE.


This has actually been an ongoing saga for many people to work out how to use memory banks efficiently. You might find some more help at
http://groups.yahoo.com/group/68HC12