Memory Segments in AVR Studio 5

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

While I understand there is some general disagreement regarding whether addresses for segments should be addressed by byte or by word, there seems to be some inconsistency even within AVR Studio 5.

In the "Memory" settings for a project, one sees the "Flash Size" listed for a given part. For example, the "Part Information" for the ATxmega256A3 shows "Flash Size: 0x42000". This is a size in bytes (256 KB application + 8 KB boot), so one might assume that the address one would be entering in the "Memory Segments" section below would be in bytes. For example, to target the boot loader, one might think it makes sense to define a flash area with name ".text" and address "0x40000", correct?

However, if one then watches what is actually passed to AVR-GCC during linking, one sees "-Wl,-section-start=.text=0x80000". That is, AVR Studio 5 has assumed that the user specified value was in words, so it's being doubled to provide a byte address to GCC. Of course, this value is now twice what it should be (and thus wrong).

Based on this, it seems as if one has to enter "0x20000" (for 256KB in words) as the "Address" under "Memory Segments", even though all the size values there are in bytes. This seems inconsistent. At a minimum, there should be a tooltip or some help text which clarifies that the value being entered is in 16-bit words. The help text currently does not provide any guidance, and there's no indication that this value will be doubled before being passed to GCC.

Am I mistaken here, or do others agree that this currently seems to be confusing or misleading?

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

The operation is that same as for AS4. Addresses are given as WORD for code flash sections but bytes for anything else. This follows Atmel's general pattern of always doing anything in connected to 16bit code flash in terms of words. The only "odd" thing is that the compiler they bolted onto the back is not there's and it chose to do everything in terms of bytes (and it doesn't even understand the concept of Harvard memory and separate addressing for flash, ram and eeprom) so Atmel make a last minute *2 when passing the entered value to a --section-start (for code sections).

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

Ahh, I see.

Well, I understand that it's a precedent (and not new in AVR Studio 5), but I personally still think it would make a lot of sense to tooltip or otherwise provide context-sensitive help that describes this in as much detail as possible. Anything and everything to minimize the chance for accidental error.

It would also be nice if the AVR Simulator in AVR Studio 5 could start running at an arbitrarily defined memory address (in bytes, or words, as long as it's specified which!). Right now, if one tries to debug a boot loader at its correct address, the simulator seems to sort of wander through memory until it eventually gets to the bootloader, completely throwing off the cycle time count.

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

Quote:

It would also be nice if the AVR Simulator in AVR Studio 5 could start running at an arbitrarily defined memory address (in bytes, or words, as long as it's specified which!). Right now, if one tries to debug a boot loader at its correct address, the simulator seems to sort of wander through memory until it eventually gets to the bootloader, completely throwing off the cycle time count.

AS4 certainly had that facility. But when I check now it seems that it's only the old "Sim1" that had it. In sim2 there does not seem to be the equivalent and given that the AS5 simulator is really just this same sim2 I'm guessing it's lost the ability.

Attachment(s): 

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

But, as you can see from the picture of the Sim2-options you can set the BOOTRST fuse and select the size of the bootsector. Enabling the BOOTRST will make most, unfortunately not all, devices start at the bootsector address, just like a real device.

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

Oh right - well that's obvious isn't it? Err... not! Time to study UI design methinks.

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

To me the two option-windows aren't that different. Sim1-option-window has a separate frame titled "Boot loader" where you enable the bootloader and selectes the size. Sim2-option-window has a list of all the fuses where BOOTRST enables the bootloader and BOOTSZ defines the size. This makes the sim2-way more similar to how it is done on a real device where you configure the fuses.

Actually all fuses are implemented, including lockbits, although not all fuses make any sense in the simulator.

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

Err, yes, but aren't all of these options missing from the simulator in AVR Studio 5? That is, if one goes to configure the properties for the AVR Simulator in AVR Studio 5 for, say, an Xmega, one has only a single lonely check box, "Use External Reset".

Hence my complaint about AVR Studio 5.

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

*blush* Well, yes, configuration of fuses for the simulator is still missing in AS5.

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

Looking at this further, the "AVR Programming" dialog in AVR Studio 5 allows one to select "AVR Simulator" as the "Tool". Using this, one can theoretically change the fuse settings and lock bits from this programming dialog. Unfortunately, the settings don't "stick" even after "programming" new fuse settings. If one changes the "BOOTRST" setting, programs it, then clicks "Read", it's always set back to "APPLICATION"; the same thing happens if one closes the dialog and re-opens it. No matter how one monkeys with this, execution always attempts to start in the application section. Hence, while one might think this would work, it doesn't.

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

This behavior is known to us, and filed as bug #13844. The fuse configuration (and flash contents) is not remembered between sessions. As soon as you close the "AVR Programming" dialog all settings are lost.