This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CE Generation for FRAM Access and pdata

Keil compiler has the provision of type specifier 'pdata' which can be used to declare variables in external memory.
For SRAM kind of memory devices we can keep the chip enable signal low and use facility provided by 'pdata'.
But for FRAM kind of chips (eg FM1608), CE signal has to have a logic low transition after address is placed then only a valid read/write operation can be performed.
But the code generated by keil dosn't give any option to modify the pdata to insert this CE logic on a port pin.
Is it possible to do anything in code to generate CE signal while accessing pdata type variables.
Thanks in advance...

  • Use the 8051's /RD and /WR signals in the normal manner?

  • Hardware design was already done. /RD, /WR signals are connected as usual, and CE signal is connected to a port pin. We need to maninpulate this pin to strobe CE for each FRAM memory access.

  • Thanks you Neil,
    You are correct, if hardware is in place it will work without any problem. Its not at all a Keil issue.
    Easiest method is to take ALE of 8051 to CE of FRAM. But, as i said our hardware already exists with a port pin connected to CE of FRAM. So we need to strobe that port pin each time a variable in FRAM is accessed.
    To tell you more, original design was with 8051 interfaced to SRAM. In a recent modification SRAM got replaced with FRAM without changing any logic. So the pdata varaiables which already exist in code can no longer be accessed properly. Ideal solution is to change the hardware.
    As an alternate solution, is it possible to modify the assembly level code for pdata.
    Compiler generates MOVX instructions for pdata type variables. If we can gain control over this assembly code generation, we can put port chaning logic there to accomplish memory read/write without changing hardware.

  • Compile through assembly, filter the assembler output and then assemble the patched assembler source.

  • Maybe the forum's working again - if so, here's what should have appeared:

    "the code generated by keil dosn't give any option to modify the pdata to insert this CE logic on a port pin."

    That's nothing to do with Keil - that's the way the 8051 hardware works!

    The MOVX instruction generates the complete memory access cycle, including /WR and /WR - You can't "break-in" to a MOVX instruction to fiddle with a port-pin part way through the memory cycle!

    See the timing diagrams on pp23-24 in Chapter 3 of the so-called "bible" for the 8051:

    Chapter 1 - 80C51 Family Architecture:
    www.nxp.com/.../80C51_FAM_ARCH_1.pdf

    Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set:
    www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf

    Chapter 3 - 80C51 Family Hardware Description:
    www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf

  • Bhaskar,

    I had a look at the datasheet of the FM1608 and it does, indeed, seem that you need to toggle !CE>

    HOWEVER, I have not known Ramtron to be that stupid (making totally incompatible chips), so I would say keep !CE low and just use !RD and !WR.

    It sounds as if you have a circuit, try it.

    Erik

  • "I have not known Ramtron to be that stupid (making totally incompatible chips), so I would say keep !CE low and just use !RD and !WR."

    They highlight in several places that this is a key difference between (their) FRAM and SRAM; it is specifically mentioned in the Datasheet, and they even have an application note on it:

    www.ramtron.com/.../AN100 - ReplaceSRAMwFRAM.pdf

    I don't think it would be wise to simply ignore this?

  • I have used lots of Ramtron chips, but only serial. I said "I have not known Ramtron to be that stupid" now I know they are. Oh, well, it may be that this was not stupidity but the only way to make the chips.

    Now we need to know which exact derivative of the '51 the OP uses since the timing of ALE/!WR/!RD varies between derivatives.

    Erik

  • That is, of course, the reason that they state - but they would, wouldn't they...?