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

DS5240 on-chip XDATA problems

Hello. I've having difficulty using the on-chip SRAM for the DS5240 and the problem seems to rest in my compiler or linker config rather than my code. Here's my simple test program:

 #include <stdio.h>
 #include <reg5240.h>

 unsigned char xdata buf[512] _at_ 0x0400;

 void main(void)
 {
    int i;
    /* setup serial port */
    while (1) {

       printf("Write (%02bx, %02bx).\n", ACON, RAMST);
       for (i = 0; i < 512; i++) {
          buf[i] = 0xa5;
          printf("Wrote byte %d.\n", i);
       }

    }
 }

As it is, this code produces erratic output - weird text, numbers and straight up garbage at times.

If I remove the absolute location specifier, everything works fine.

Reading through the knowledge base, problems of this sort are usually the result of not enabling the on-chip SRAM. The DS5240 data sheets claim the on-chip SRAM is enabled by default and the two registers I print out (ACON and RAMST) confirm this.

I am using the LARGE memory and code models. Off-chip Xdata is configured to start at 0x0 with a size of 0x20000.

For reference, this Dallas chip has the following internal XDATA-mapped memory organization:

 0x0000-0x03ff : RAM0 : Vector Memory
 0x0400-0x07ff : RAM1 : Data Memory
 0x0800-0x13ff : RAM2 : MAA Memory

My feeling is that I'm missing some peculiarity of the chip, but the data sheet makes it all seem pretty straightforward. Adding the STARTUP390 code doesn't seem to help anything, either. I'm just not sure what else to even try.

So thanks a lot for any ideas you can offer!

0 Drew Davis over 21 years ago

I think you'll have to get us a Q-clearance card before we're cleared for that sort of information. (And besides, how do we know that you're really Jay Miller?) But, some guesses based on what Dallas will let me access:

How about the MCON settings? The partitioning between data and program store might be particularly relevant if your program fails to work at all, rather than just getting garbage in buf[] alone.

Since this device has two busses, are you sure your xdata is connected to the right one? See the EXBS bit in RPCTL. If you're using the encrypted memory bus, is the encryption set up right?

Are you using the device in extended addressing (MX) mode (and the compiler to match)?
Cancel
Vote up 0 Vote down

Cancel
0 Jay Miller over 21 years ago in reply to Drew Davis

Heh - you mean this thing isn't covered under fair use?

Those are good questions - I'll see if I can provide some answers.

Regarding MCON, I am operating in non-partitioned mode according to the bootloader. The contents of MCON confirms this. Also, I believe the partitions (if they were in effect) begin after the internal SRAM addresses anyway. So I don't *think* that's it.

I'm not sure exactly how to answer the bus questions. For one, I haven't changed whatever default settings have some effect. Secondly, it was my (possibly mistaken) impression that mapped XDATA is not encrypted, which I thought had to do with the two buses - an internal and external bus, no? My impression is that only the external bus carries encrypted instructions.

I also can't find any info on EXBS or RPCTL..?

The memory configuration is set up as a standard 16-bit 8051 for now - the default. I have also tried the extended linker and assembler provided by Keil (LX51 versus BL51 and AX51 versus A51) - but I see no changes in the program's behavior.

Hopefully this'll prompt some other ideas.. surely it's something simple!
Cancel
Vote up 0 Vote down

Cancel