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

xdata on MSC1200Y3

From the TI MSC1200Y3 documentation there is supposed to be 1024 bytes of xdata (0-0x400) available on the device. The following simple program compiles and links with no errors, but when it runs the output value shows 0xFFFF as though there is no RAM there. It runs as expected in the simulator. It runs as expected if XDATA is defined to idata, so it is probably not a logic or compiler issue.

I've tried setting the Target Options "Off chip Xdata Memory" to :
Start = 0
Size = 0x400
and I've tried modifying the Startup.A51 values:
XDATASTART EQU 0H ; the absolute start-address of XDATA memory
XDATALEN EQU 0400H ; the length of XDATA memory in bytes.

But neither of these have helped, I still get 0xFFFF when reading xdata memory.
I dont see any SFR for memory control that would limit this access.

Do I need to set the xdata memory range through the GUI or in Startup.a51 or both?

Is there some other tool setting that I'm missing?

Any help would be appreciated...
==============
#define XDATA xdata
// #include <REG1200.H>
sfr TCON = 0x88;
sfr CKCON = 0x8E;
sfr MWS = 0x8F;

#include <stdio.h>

extern void autobaud(void);

#define ARRAY_SIZE 10

void main(void)
{
unsigned int idata i;
int XDATA dd[ARRAY_SIZE];

CKCON = 0x10;
TCON = 0;
autobaud();

for (i=0; i < ARRAY_SIZE; i++) dd[i] = i;
printf("dd[8] = %x\n", dd[8]); /* = 0xFFFF = wrong! */

}

Parents
  • It is probably me that is missing something (like internal RAM). I can't find a "Use on-chip xdata memory" option in the tool which is a hint - plus the behavior I'm seeing.

    There is a figure in the data book that led me to believe there was some, but I guess not.

    I guess I need to partition the flash between code and data.

    Thanks

Reply
  • It is probably me that is missing something (like internal RAM). I can't find a "Use on-chip xdata memory" option in the tool which is a hint - plus the behavior I'm seeing.

    There is a figure in the data book that led me to believe there was some, but I guess not.

    I guess I need to partition the flash between code and data.

    Thanks

Children
  • each and every chip I know that has internal XRAM need a bit in some SFR (often AUXR1) set to access it (Typically default is "standatd '51" = use external RAM). I have no idea where the bit is and what it is called in your derivative, you will need to consult the datasheet.

    Erik

  • It appears that the MSC1200Yx family is not capable of supporting any xdata memory, so there is no SFR register associated with it.
    thanks

  • It appears that the MSC1200Yx family is not capable of supporting any xdata memory, so there is no SFR register associated with it.

    not a foregone conclusion. I do not remember which, but I got cought on that one once. Another "famiuly member" was external RAM capable, so even the members not so needed the bit set.

    anyhow, you are totally wrong. From the datsheet:

    • Memory Write Pulse (WR) which is idle high. Whenever a external memory write command (MOVX) is executed then a pulse is seen on P3.6. This method can be used only if CPOL is set to '1'.

    Erik

    I',m sorry, you sucked me into spending time on the datsheet of a device I do not know.

  • "anyhow, you are totally wrong."

    Sometimes you really are an ***.

    Go and look at the datasheet again.

  • Go and look at the datasheet again.

    Why?

    as qyoted
    From the datsheet:

    • Memory Write Pulse (WR) which is idle high. Whenever a external memory write command (MOVX) is executed

    Erik

  • "Why?"

    Well, you might notice that statement appears in the description of methods of driving the SPI clock and has nothing to do with external bus access.

    You might also notice the lack of a port 0 or a port 2 in the pin description, little things like that.

    What I'm really saying is don't be so damn aggresive with someone who has obviously made a considerable effort to solve his own problem. You then glance at a datasheet for two minutes and tell him rudely that he's wrong. In this particular case, however, you are the one who's wrong.