Does avr-gcc initialize external RAM? If yes, then how can I turn that off?

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

I want the external RAM to be initialized in the Boot Section and not in the user's application. However, the user should have external RAM set up by the linker so that .data, .bss and .heap are after the end of SRAM while the stack pointer is at the end of SRAM. How can I do that?

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

I think that by default the avr-gcc ignores the possibility of external RAM.

Have the bootloader flip whatever bits it needs to to access external RAM and flip them back again before starting the loadee.

In the main program, flip them yet again.

Iluvatar is the better part of Valar.

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

The thing is that the bootloader will have an RTOS and its data must NOT be corrupted by the loadee's initialization.

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

To answer the question in the thread title (which doesn't appear to be what the first post asks), no GCC does nothing to initialize anything in RAM apart from the .data and .bss loops. No more, no less. 

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

Perfect! Thanks!

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

BTW it only takes about 1 minute to write an empty main() with one .data and one .bss variable, compile, link then study the .lss to see exactly what the CRT does/doesn't do. 

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

I'm a bit lost, with a stated RTOS in the bootloader, and no mention of the indeterminate state of SRAM after a power cycle or brown-out.  But whatever, I guess.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

So the RTOS gives a menu on the screen with a Run and Load button. When Load is pressed, it lists contents of an SD card and allows selection of a HEX file to bootload. When Run is pressed, the RTOS makes two tasks; one for the system stuff like reading from the SD card, accessing memory beyond 64kB, etc. while the other one is the Application Section. So when the Application Section is run, it mustn't reinitialize (which is reset) the RAM because it will destroy the contents of the kernel (which is the list of tasks, resources, etc.).

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

Shouldn't a bootloader simply bootload? Nothing says (when using SPM) that you have to replace the entire app section so I'd keep part of it for the "OS" and then have a replaceable "slot" into which the game images are programmed (bin not hex obviously - no point wasting AVR space with a hex decoder!).

 

What's the strategy for the app space IVT? Is that "owned" by the OS or is it owned by the delivered app? I guess it has to be the former which adds to the argument for having some OS parts in app space. But if the OS does own the vectors then how does the app get access to any vectors it needs? Ram based function pointers? Or does the app live in a protected environment where it doesn't get to mess with ISRs (presumably all it really needs are timers and the OS can provide that off the back of a h/w timer ISR).

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

Interrupt happens > Interrupt vector from Boot Section's IVT is fetched > CPU runs the OS's interrupt handling code if it exists > CPU jumps to the Application Section's interrupt vector > Application Section's ISR is run.

 

That's why I wanted to put the OS inside the Boot Section so that it has a protected space without interfering with the Application Section. But I might use a part of the Application Section if the Boot Section has no more space for the OS.

 

Some interrupts like for the SD card, MP3 codec chip, USART, USB, etc. will be completely handled by the OS and not by the user application. This is because only the OS knows where it left of in the communication with the SD card and the MP3 chip and only the OS should because I want the user to be free from all of those stuff. Therefore, the OS also serves as a background resource loader like loading the MP3 file piece by piece and sending it to the MP3 codec chip, 50fps/60fps screen rendering from the video buffer from the external RAM onto the TFT screen or maybe some day onto the TV via HDMI, VGA or AV.

 

Now this is off topic and I'll have to make a thread for my project to have everything in one place.

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

That's why I wanted to put the OS inside the Boot Section so that it has a protected space without interfering with the Application Section.

I thought the Xmega had 3 protectable sections. While tiny/mega just have app/boot I seem to remember that Xmega has app/data/boot. So you could put the OS in "data". But surely the only protection it really requires is not being SPM'd? If that;s the case you just have the SPM code in the bootloader police a range of memory that it won't accept for SPM?

 interrupts like for the SD card

Why would you ever use interrupts for SD (or more generally SPI)? You'll get more performance out of a polling loop every time.

Last Edited: Mon. Jun 29, 2015 - 03:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I wasn't thinking well. I didn't know that SD card doesn't need ISR.
 

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

I wouldn't worry about the SD thing anyway - you'll be using FatFS I guess and it does SPI polling anyway.

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

I wouldn't worry about the SD thing anyway - you'll be using FatFS I guess and it does SPI polling anyway.

I suppose that is strictly true -- or is it?  One has to provide suitable SPI primitives to FATFS.  If one would choose to use the SPI interrupt, and then poll for a results flag in the primitive--you could do that, right?  Of course, each byte would take like 2x the cycles vs. "inline".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

And what would be the SD card's maximum SPI clocking?

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

From Chan's site:

 

Obviously that is on a 9.2MHz (?) mega64. The SPI on an a 32Mhz Xmega could presumably go quicker. However the different speeds for different SD cards there suggest the limit might be more to do with the SD card used than the code/interface that is driving it.

 

Obviously look at "class 10" (or whatever the latest is) SD cards.

Last Edited: Tue. Jun 30, 2015 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Obviously look at "class 10" (or whatever the latest is) SD cards.

Indeed.  Even lowly Class 2 is 2MB/s which would be a min 16MHz SPI clock, with no overhead.  So I'd guess that a conforming Class 2 would support 20MHz+ SPI clock rates and multiples of that for higher class numbers.  Higher than AVR8.  In general, higher than Xmega also.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Can the SPI be clocked higher than the XMEGA CPU? And can different SPIs have different clock sources? I'll have an SD card, SDRAM and Flash storage chip. They can be clocked higher than XMEGA (except for SD cards equal to or under 4MByte/s). I know that SDRAM can have higher clock source than CPU, but I don't know about SPI for a Flash storage chip. Maximum frequency of that one is 180MHz.
 

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

Can the SPI be clocked higher than the XMEGA CPU?

???

 

Dunno.  I'm not a heavy Xmega person.  Is your question really "if I clock the Xmega at 32MHz, can I have a faster SPI clock?"

 

Or is it "If I use a clock divider to run my Xmega at 1MHz, can I run a faster SPI clock?"

 

The Xmega A Manual sez:

 

Now I guess you want me to find in the fine manual which clock(s) for SPI...

 

The answer appears to be "no".

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Jun 30, 2015 - 03:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said above: Chan's benchmarks are for a 9.2MHzx mega64 and yet when you look at the graphs it's clear some cards are better performers than others. The implication of that is surely that you are approaching the card limit at well below what even SPI on a 9MHz CPU can do so even if you switch to a 32MHz one it's not going to help because the limit is the card not the SPI.

 

Having said that Chan's benchmarks are old and for old, low capacity cards (I think it even predates the "class" system for SD) and there are now cards that can operate much faster so I think you'd need to re-do the benchmarks using the 32MHz CPU and the specific card you plan to use and see how you get on.

 

Having said THAT the "class 10" thing is talking about the MAIN interface of the SD card - the 4 wire one - the one we cannot use - so the fact you are going to be stuffing everything up/down one data wire may mean that the class rating is moot - I doubt they optimise the SPI interface that's only there for backwards compatibility with really old MMC equipment.

 

And finally, having said all that, exactly where in your design does SD/MMC speed matter anyway? As I understood it you are giving the user a choice of games to load at "boot time". If the game takes 10 seconds to load instead of 8 does it actually matter?!?

 

You weren't planning to do real time data transfer during the game operation were you? (like loading BMPs on the fly or something?). Or is this about streaming MP3 data to VLSI VS1005 or something?

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

When the player goes to a level transition, the new level layout should load from the SD card. During that, the MP3 file should be streaming. You know, like on PlayStation. Loading loading loading. That's how I imagine my console. I'll be using VLSI1053.

 

Also, another thing. If during continuous data sending over SPI the XMEGA starts going a bit late because of processing something else, will the operation be interrupted? I mean this for SD cards and Flash memory chips. Or if I use software Quad SPI, will it be bad if all bytes are not 100% synchronous? Like if some instructions during sending take 8 CPU cycles total while some 10 or 6. I want to know this also because of USB. If XMEGA doesn't respond on USB in a specific time, I'll have to hang up on SPI stuff. But is hanging up SPI like on 5th byte out of 10 bytes a good idea or will malfunction/communication error occur on the slave SPI chip? Also, does the ATXMEGA128A1U USB module take care of pinging and timing and everything or do I have to intervene with my extra code? If I'll be using hardware Single SPI, I'll have to use polling and that will cause slight latency. Is that fatal for communication?

 

Long story short, is this SPI time sensitive like rendering NTSC picture on a TV?

 

And are you saying that the class 10 is impossible to handle by XMEGA? I need to specify that on the product then or maybe add more compatibility.

 

My Ready for XMEGA board has 32MHz crystal as much as I think (it has ATXMEGA128A1 not ATXMEGA128A1U). Here in the datasheet, it says XTAL 0.4-16MHz. Does that mean that the crystal should be 16MHz with 2x speed for max CPU speed or can it be 32MHz with no extra speed-up tweaking?

 

If I'll have a precise RTC that will count time and date, will I have to then have total 2 crystals? One for the 32kHz ports and one for 32MHz ports.

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

Long story short, is this SPI time sensitive like rendering NTSC picture on a TV?

Woah! If you are planning on doing soft VGA/PAl/NTSC then you will have virtually no time for anything else. I'd consider putting in a dedicated micro as a video generator.

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

If I'll have a precise RTC that will count time and date, will I have to then have total 2 crystals? One for the 32kHz ports and one for 32MHz ports.

Here we go again... define "precise".  Will you get, in the end, more useful results from an untrimmed watch crystal vs. the 32kHz already provided on the Xmega?  (There is a thread on this -- even the "standard" atomic clocks around the world are averaged.  So those aren't "precise" either.  [I guess that would be absolutely "accurate", to be pedantic.  Your watch crystal or the internal 32kHz will be precise to one tick.  Whether it is accurate or not is another matter.])

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

clawson wrote:

Long story short, is this SPI time sensitive like rendering NTSC picture on a TV?

Woah! If you are planning on doing soft VGA/PAl/NTSC then you will have virtually no time for anything else. I'd consider putting in a dedicated micro as a video generator.

He didn't say he was doing any such thing.

He was asking, How picky is SPI?

The answer is not very.

That is what the SPI clock signal is for.

SPI is not fussy about how fast you transfer bytes.

 

The protocol on top of SPI might be another story.

 

Iluvatar is the better part of Valar.

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

So many questions, so little research. Yes, USB will require intervention on a regular basis. Read the LUFA docs.
Interrupting spi comms is usually not a problem. Since you're the master, you dictate the timing. Soft quad spi vs hardware spi? Hardware will probably win. Use your mad assembler skilz to write a tight quad spi implementation. Count the cycles. You also need to read/write the data and manage pointers etc, so it might be a case of diminishing returns. Get it working first then measure.

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

Thanks, skeeve. Now I understand.

 

I wasn't going to do any NTSC stuff anyway. I might in the future if my console will have a dual port SDRAM where there's the primary XMEGA and the secondary one that uses the SDRAM for rendering PAL picture. (PAL because I'm in Europe and PAL is underrated).