Xmega with external SRAM

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am using an ATXmega128A1 with external SRAM (EBI). Right now I only use the direct addressable part of the SRAM from 0x4000 - 0xFFFF. I've got the impression that everything works fine.

But I have got a SRAM test function which you can see below:

bool ext_sram_test(void)
{
  uint16_t *psram;
  uint16_t iii;
  uint16_t err;

#define SRAM_ADDR 0x4000
#define SRAM_SIZE 0xC000


  psram=(uint16_t *)SRAM_ADDR;          // set pointer to begin of SRAM
  err=0;                                // error counter

                                        // write pattern inro SRAM
  for (iii=0; iii < SRAM_SIZE/2; iii++)  
  {
    *(psram++)=iii;
  }
  
  psram=(uint16_t *)SRAM_ADDR;          // set pointer to begin of SRAM

                                        
  for (iii=0; iii < SRAM_SIZE/2; iii++) // verify pattern
  {
    if (*(psram++)!=iii)
    {
      err++;
    }
  }

  if (err)
  {
    return false;
  }
  else
  {
    return true;
  }
}

The first loop which writes the simple pattern into SRAM works fine. If I set a breakpoint behind it I can see the pattern in the memory window of my debugger. But stepping forward into the verify loop leads to the bug. Reading the data does not work. It seems like reading random data.

The funny thing is if I reduce the size definition of my SRAM by 2 bytes everything is fine:

#define SRAM_SIZE (0xC000-2)

The verify loop detects no errors anymore.

I wonder if this is a compiler bug. Can anyone help me?

Actually my workaround is to reduce the SRAM_SIZE. The SRAM test and also the usage of external SRAM in other parts of my software works fine.

I am using Atmel Studio 6.1.2730 SP2 with the suiting AVT-GCC compiler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wonder if this is a compiler bug.

Let's face they usually are aren't they ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Let's face they usually are aren't they :wink:
Of course you are right. Usually the problem is located between chair and PC keyboard. :wink:

In between I doublechecked the problem with AVR Studio 4.19 and the good old WinAVR-20090313. Here I can reproduce the same effect.

But I recognized a difference between AVR Studio 4 and Atmel Studio 6.1. The old AVR Studio shows me in its processor tab the Z pointer as 24 bit value. Which is correct because the RAMPZ has to be concatenated. Atmel Studio 6.1 only shows 16 bit.

And that's why I came a bit closer to the bug. Attached you can see a screenshot of my debug session. In this situation the XMEGA should read from address (psram=)0x4004 (nearly the beginning of the external SRAM). But the RAMPZ is 1 which makes the Z-Pointer to 0x14004 instead of 0x04004. At the end of the write loop the RAMPZ became 1 and it is not resetted to 0 by

psram=(uint16_t *)SRAM_ADDR;   // =0x4000

But if I reduce the write loop by 2 like I mentioned in my first post RAMPZ never becomes 1 and then it works.

So the questions are:
1. Why is RAMPZ not resetted?
2. Why does Atmel Studio 6 does not show me RAMPZ?
and to clawson:
3. Isn't it a compiler bug? :lol:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ce wrote:
3. Isn't it a compiler bug? :lol:
Avr-gcc supports for "normal" pointers only a 16 bit address. With the ++ in the last loop iteration you are moving the pointer "outside" of this addressable area. I am not familiar with the standard in this respect, but it wouldn't surprise me if overflows for pointers are not defined.

Stefan Ernst