What is this mysterious `scratch RAM` in the S12P?

[slartibartfast]

Hello all,

I am looking for info about the scratch RAM which is mentioned as being a part of the DFLASH resources in the S12P. The reference manual is completely tacit about it besides mentioning it as `being there` at G:0x05800--0x05AFF. Any hints?

regards,

slarti

[MCB]

Hello,

I hate to "Bump" a dormant topic, but I, too, would like to know about the "scratch RAM."

Is it used by the flash module internally, or might it be available to store a copy of a sector for erasure and reprogramming?

I also noticed that in Table 13-5, page 431:

        Global Address                | Size (Bytes)    | Description

        0x0_5800 – 0x0_5AFF    | 768                 | Memory Controller Scratch RAM (RAMON(1) = 1)

that RAMON has a footnote:

         1. MMCCTL1 register bit

but the only other locations this register is mentioned are Revision Histories, page 2 and page 107:

        Removed reference to MMCCTL1 register from Table 13-5

        Removed references to the MMCCTL1 register

(of course the first mention is blatantly wrong)

It seems to me that this could be a unimplemented feature that evaded proofreading, but I want to know for sure.

Regards,

Michael

[kef]

How I see it. S12XE appeared before S12P, and S12XE had hardware EEPROM emulation. S12XE flash memory controller allowed to partition DFLASH, so that one part of it is used for EEE (emulated EEPROM), and another one as a flash. EEE when enabled, allows user to write to scratch RAM, and S12XE flash memory controller takes care about how to make this RAM nonvolatile. Part of scratch RAM, not used for EEE can be used by user as a regular RAM.

.. and then newer cheaper MCUs like S12XS and S12P saw the sunshine. They have EEE feature disabled, but scratch RAM is still here. Since EEE is not available, you can use this RAM for your own purposes.

[MCB]

Well, regardless of what the datasheet says, I was unable to write to the address space, either globally @0x05800--0x05AFF or locally at the same offset from local DFlash as it was from global DFlash. Specificly, I noted 0x5800 (Scratch global) is 0x1400 from 0x4400 (DF global), so I tried 0x0400 (DF local) + 0x1400 = 0x1800 (scratch local??). It did not write.

kef - you said "scratch RAM is still here"

Do you know that for sure, or was it an postulation?

~However~

I did find an extra 4K of ram from 0x2800 to 0x3800.... on the P32. It is documented that it should be there on a P128, but the P32 is only supposed to have a total of 2K RAM.

But I should probably drop this into its own thread.

[kef]

No, I haven't put my thingers on S12P yet.

Aha. In S12XS datasheet it is said that MGRAMON bit (bit7 of) MMCCTL1 register @0x13 is clear by default on reset. So one has to set it to get access to scratch RAM.

It is surprising that S12P datasheet doesn't tell where RAMON or MMCCTL1 register might be. It is mentioned that at address 0x13 is some reserved register, which you are not supposed to touch. CW S12P header also seems to have no RAMON or MMCCTL1 reg defined. Certainly S12P datasheet is not complete. Either there's scratch RAM and they forgot to document RAMON bit address and register, or there's no scratch RAM at all. I think you should file service request for this.

I don't think it should be available in local memory space. Table 1-3 on page 26 in S12P datasheet says that only

0x0_4400 - 0x0_53FF part of global addresses is available locally.

Though you boght P32, probably you got maskset and device of bigger S12P. Next time you may get P32 with no RAM at 0x2800.