9S12C: Reading target memory size from mcu

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

9S12C: Reading target memory size from mcu

Jump to solution
1,408 Views
crane
Contributor III

Hi.

 

I'm using a HC9S12C64 in a product, which after numerous updates now is close to its memory limit. The plan is to migrate to the 128k version, thus extending lifetime of the product. The larger chip is pin compatible, so there is no problem there.

 

However, future updates will require that the programming software can find out the target size of the mcu in order not to try to update 64k mcus with out of range code generated for 128k target. The flash loader in the mcu is general, and doesn't care of its target size. Nor do I want to compile the loader for different targets.

 

Question:

Is there a register in the mcu which tells the size of its memory, or do I have to use some akward  method such as making trial reads and catch the illegal address reset or something in order to find out.

 

Håkan

Labels (1)
0 Kudos
1 Solution
739 Views
kef
Specialist I

On C32, only single least significant bit of PPAGE is used. So writing 0x3F, 0x3D, 0x3B, 0x39, 0x37, .. to PPAGE maps the same piece of flash to page window.On C64 only two least significant bits of PPAGE are used. PPAGE=0x3F, 0x3B, 0x37 .. maps the same piece of flash to page window. Etc.

View solution in original post

0 Kudos
7 Replies
739 Views
kef
Specialist I

There're PARTID and MEMSIZ registers, but according to the datasheet, C64 and C128 may have same PARTID and MEMSIZ settings. 

It is easy to determine from bootloader how much flash do you have. Read vectors block at 0xFF00 and compare it to page 0x3D, offset 0xBF00. If it compares equal, then you have 32k of flash. Else if vectors compare equal to page 0x3B, then you have 64k. - "- to page 0x37 -"- 128k. But I'm not sure about 96k derivative.

 

0 Kudos
739 Views
crane
Contributor III

I don't quite follow. Regardless of memory size, the non-banked address range 0xC000 - 0xF000 corresponds to page 0x3F:0x8000 -0xBFFF, which would put 0xFF00 at 0x3F:0xBF00 for any size of memory.

0 Kudos
740 Views
kef
Specialist I

On C32, only single least significant bit of PPAGE is used. So writing 0x3F, 0x3D, 0x3B, 0x39, 0x37, .. to PPAGE maps the same piece of flash to page window.On C64 only two least significant bits of PPAGE are used. PPAGE=0x3F, 0x3B, 0x37 .. maps the same piece of flash to page window. Etc.

0 Kudos
739 Views
crane
Contributor III

Thanks kef,

 

I just found the table, 1-11, in the manual. However, it seems that the 3F mapping is equal in C64, C96 and C128. Could that be a typo?

 

I'll do some testing and come back.

 

Håkan

0 Kudos
739 Views
kef
Specialist I

Freescale often sales bigger chips labeled as a smaller ones, until smaller maskset is released. I was receiving S12XDT256 for a long time, which had 512k of flash inside. I think this is what you see in the datasheet. If you look at PARTID description, you will note that there's no dedicated C64 maskset and PARTID value. Instead, the same maskset is used for C64, C96 and C128. I think table 1-11 is right, but only for 128k parts labelled asl C64. C64 mapping for page 3F should be $03,$07,$0B,$0F,$13,$17,$1B,$1F,$23,$27,$2B,$2F,$33,$37,$3B,$3F. What you see in Table 1-11 is valid for C128.

0 Kudos
739 Views
crane
Contributor III

Thanks again kef,

 

I recognize the down labeled phenomenon. Had an issue with it some time ago. Now if this works properly, I won't have to change anything in my loader, since it supports memory reading. Only the PC programming software needs to be supplemented.

0 Kudos
739 Views
crane
Contributor III

Turns out that in fact my 64k chips are indeed 128k. I'll start a new thread on this issue.

0 Kudos