• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 13 subscribers
  • Views 588 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Jay Miller
Offline

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
  • 0 Offline

    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)?

Reply
  • 0 Offline

    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)?

Children