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!

Parents
  • 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!

Reply
  • 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!

Children
No data