Headache due to Atmel answers

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

I asked a question from Atmel support:

Quote:
Accoring to ATXMEGA128A1 datasheet, SDRAM start address (base address) can be from 0x4000. Also the maximum SDRAM size is written 16MB. The main question is the maximum SDRAM size.
Is it 16MBytes or 16MBytes-0x4000=0xFFC000?

First answer:
Quote:
With regards to the implementation of the SRAM/SDRAM interface to the XMEGA, we have an application note AVR1312: Using the XMEGA External Bus Interface and the driver interface written in C is included. This application note details the usage.

I wrote:
Quote:
I have read AVR1312 and there is noting about my question in this text. I repeat the question:
which one of the following is the maximum reachable SDRAM size (ATXMEGA128A1):

0xFFC000 = 16760832 = 0x1000000 - 0x4000 Bytes (0x4000 is the next address after internal SRAM)

or

0x1000000 = 16777216 Bytes?


Second answer:
Quote:
Please refer to section `4.9 External Memory' in the XMEGA A manual.The external memory address space will always start at the end of internal SRAM.

:?:

Ozhan KD
Knowledge is POWER

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

Why not just test it for yourself? Do you have 16M x 8 of SDRAM ?

The Xplained boards have got 8MB onboard SDRAM by using a 16M x 4 bit chip.

I don't know how you would connect a second 16Mx4 chip. You might need a separate buffer or latch.

There is a similar anomaly with external SRAM on a mega64 type of chip. e.g. when you use 64kB of external RAM.

I have never used all of the address lines. So I have never tried it.

David.

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

Doesn't the Data Memory Map in the XMega-A manual answer your question? The highest possible address is 0xFFFFFF and it shares address space with I/O Mem, EEPROM and internal SRAM. If the external RAM starts at 0x4000, then the maximum (usable) external RAM size is 0xFFFFFF - 0x4000 (+1).

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

When I'm getting flustered over this sort of thing, I'm usually looking in the wrong part of the manual :wink:

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

david.prentice wrote:
Why not just test it for yourself? Do you have 16M x 8 of SDRAM ?

The Xplained boards have got 8MB onboard SDRAM by using a 16M x 4 bit chip.

I don't know how you would connect a second 16Mx4 chip. You might need a separate buffer or latch.


I have my own made hardware.
snigelen wrote:
Doesn't the Data Memory Map in the XMega-A manual answer your question?

The problem arised from the comments at the beginning of ÙŽAVR1312 example code:

/*! \brief Memory block to use in the memory map.
 *
 *   This depends on the size of the RAM. It can be up to (16MB/RAM_SIZE - 1).
 *   In this example the RAM size is 8MB, so the block can be either 0 or 1.
 */
#define MEMORY_BLOCK 1

/*! \brief Address where we want SDRAM to be accessed. */
#define SDRAM_ADDR (SDRAM_SIZE * MEMORY_BLOCK)

SDRAM_ADDR is used as base address in the code. By assuming RAM_SIZE=16MB, SDRAM_ADDR=0 and this cannot be correct if the first correct address is 0x4000 (The comment denotes 0 is a valid value for MEMORY_BLOCK).

Ozhan KD
Knowledge is POWER

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

You should never worry about the chip's internal addressing. Just compile your code and let the Compiler / Linker sort it out.

For example, you first C variable is actually at 0x60 or 0x100 in a regular Mega chip.

So you only get 0xFF00-IRAM usable external RAM with a Mega. Likewise, I suspect you get your 0xFFC000 usable SDRAM.

Try it and see for yourself. I guess that writing to 0xFFC003 would give you R3. It is easy enough to test non-destructively.

David.

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

david.prentice wrote:
You should never worry about the chip's internal addressing. Just compile your code and let the Compiler / Linker sort it out.

This case is not an internal addressing (doing by compiler) and you should determine the SDRAM base address by setting ٍEBI registers. If 0x000000 cannot be the base address, then َAVR1312 comments is not correct and the minimum base address must be 0x4000 for ATXMEGA128A1 and 0x3000 for ATXMEGA64A1.

Ozhan KD
Knowledge is POWER

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

Quote:

then ÙŽAVR1312 comments is not correct

In my experience comments in code are OFTEN wrong or misleading. I wouldn't put too much faith in them speaking the gospel truth. Like David I would have thought the easiest way to find out was to try it.

When working with an Xmega with 16MB attached I'm sort of assuming that for a design of such potential complexity you are also using a PDI/JTAG debugger? If so you probably don't even need to write test code - just some memory writes in the debugger should reveal the lay of the land.

Last Edited: Thu. Aug 8, 2013 - 04:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

electronic.designer wrote:
This case is not an internal addressing (doing by compiler) and you should determine the SDRAM base address by setting ٍEBI registers. If 0x000000 cannot be the base address, then َAVR1312 comments is not correct and the minimum base address must be 0x4000 for ATXMEGA128A1 and 0x3000 for ATXMEGA64A1.
From the XU manual: "If the address space is set to anything larger than 4KB, the base address must be on a boundary equal to the address space. For example, with 1MB address space for a chip select, the base address must be on a 1MB, 2MB, etc. boundary."

0x0 is perfectly valid base address too. Except that in this case you "lose" part of SDRAM that overlaps with the internal memory.

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

The CodeVision Wizard gives you all sorts of different options. Some of which imply that you can have four different Chip-Selects and map up to 16MB for each bank.

No. I have not read the Data Sheet.

I would start with the CodeVision or Xplained board examples. I guess that they start at 0x000000. But you could map them however you want.

I suspect that you might run into register or SFR space when you get to the begin or end of the 16MB. i.e. like a mega64 or mega8515.

However, starting with the Xplained examples, you can do your own tests.

Like Cliff, I would have a healthy scepticism about app note comments and even the official data sheet. Do your own tests and give the app note authors marks out of 100 for accuracy (or not).

It will mean that you can help the next 16MB user.

David.

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

ezharkov wrote:

0x0 is perfectly valid base address too. Except that in this case you "lose" part of SDRAM that overlaps with the internal memory.

I agree.
david.prentice wrote:
Do your own tests and give the app note authors marks out of 100 for accuracy (or not).

I will do my tests. But the main question is what is the atmel support responsibility? Didn't they know the correct and exact answers? And why should I guess and try technical solutions by myself?

Ozhan KD
Knowledge is POWER

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

Atmel Tech Support don't seem to know much about the Xmega.

I asked what I thought was a simple question:

Which I/O pins are powered by AVcc instead of Vcc?

The manuals are not clear on this.

It matters for a low noise design. One can be sure to put the digital I/O on digital (Vcc) powered pins, and help to keep the analog supply less noisy.

First answer was an image of the chip's pin out, copy/pasted from the manual. Pin whatever is the Avcc pin.

I repeated the question, worded slightly differently, and got an equally unhelpful answer.

Xmega Support clearly isn't one of Atmel's strengths at the moment.

JC

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

I can't help thinking first line support may be "outsourced" to reduce costs.

(we do, however, know that some of their support is staffed by some very talented staff but you maybe don't hit those at the first level - I think they call it "triage"?)

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

Atmel final response:

Quote:
Yes, in the 24-bit bus internal SRAM gets high priority followed by external memory (through chip select).

The actual external memory is (16MB- internal RAM size).

Ozhan KD
Knowledge is POWER

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

electronic.designer wrote:
Atmel final response:

Quote:
Yes, in the 24-bit bus internal SRAM gets high priority followed by external memory (through chip select).

The actual external memory is (16MB- internal RAM size).


That's not true.
16MB - internall addressing space = 16MB - 16KB.

electronic.designer wrote:

This case is not an internal addressing (doing by compiler) and you should determine the SDRAM base address by setting ٍEBI registers. If 0x000000 cannot be the base address, then َAVR1312 comments is not correct and the minimum base address must be 0x4000 for ATXMEGA128A1 and 0x3000 for ATXMEGA64A1.

Minimum valid base adress is 0x000000. In Atxmega128a1 case(I'm testing on it) EBI remains inactive for adresses below 0x4000. Technically You're loosing that memory. But it's only valid Base address for 16MB in single chip.

Last Edited: Mon. Aug 12, 2013 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
their support is staffed
Are you sure you don't mean "their support is stuffed "? :mrgreen:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

david.prentice wrote:
The CodeVision Wizard gives you all sorts of different options. Some of which imply that you can have four different Chip-Selects and map up to 16MB for each bank.
(...)

And You can do it. At least with SRAM.
In case of overlaping memory spaces Chip-select with lowest number gets priority.
example(tested on atxmega128a1):
CS0: 256 bytes @0xf000 (EBI_CS0_BASEADDR = 0x00f0;)
CS1: 64Kbytes @0x0000 (EBI_CS1_BASEADDR = 0x0000;)
CS1 is active from 0x4000 to 0xEFFF
CS0 takes over 0xF000 to 0xF0FF
CS1 covers 0xF100 to 0xFFFF