What's behind a Reserved SRAM address?

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

When I write data into a Reserved SRAM address it sometimes works out well, sometimes influence on periferals.
Are there lists available what is behind a Reserved address on each AVR device?
Are all registers doing something even when you do not notice? Seems like there is more in there.

	sts	0x00, XL
	sts	0x01, XH

Does work. (but maybe not when you use the ADC, or another timer or PIN.)

RES

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

RES wrote:

	sts	0x00, XL
	sts	0x01, XH

Does work. (but maybe not when you use the ADC, or another timer or PIN.)


There's no reserved memory at addresses 0x00 and 0x01, that's the register file.

JW

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

What is a "Reserved" SRAM address on an AVR? Where did you see that term used for an AVR?

What part of the answer to your question is >>not<< in the datasheet? Please be specific. In particular, note which, if any, parts of the answer to your question are >>not<< addressed in the small picture titled Data Memory Map. I can see where this might be obscure, being in the "SRAM Data Memory" section and all. :roll:

I guess you are a bit lonely on this Sunday and needed to try to construct an off-the-wall stumper for us as is your wont from time to time.

Lee

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

Out of SRAM on this homebrew project and see a lot of Reserved registers.

RES

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

"Reserved" means "don't touch". There may be ANYTHING behind it.

JW

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

While I can tell that's an AT90PWM it's not certain which one it but I just picked any AVR datasheet at random and it contains:

Quote:
For compatibility with future devices, reserved bits should be written to zero if accessed. Reserved I/O memory addresses should never be written.

But your example code above was writing 0x0000/0x0001 - as already said, these are not SFR/IO addresses - but the registers of the AVR - you were writing to R0 and R1

(EDIT: looking at some of your previous posts I guess it may be an AT90PWM3B you are using - that datasheet contains exactly the same quote as above)

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

I think there is nothing behind a reserved address. Data written goes to /dev/null and attempting to read it probably returns junk.

If your out of SRAM you should find ways to reduce SRAM requirements, use an device with more RAM, add external RAM, or give up.

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

jayjay1974 wrote:
I think there is nothing behind a reserved address. Data written goes to /dev/null and attempting to read it probably returns junk.
This might not be true. As a result of optimisation, the reserved address writes AND reads might actually alias a real resource, or they might even result in some other unwanted behaviour.

Reserved is simply a no-no, fullstop.

JW

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

We cannot say with any confidence what might and might not happen. Therefore, RES should follow the datasheet recommendations and not use reserved locations.

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

reserved addresses are not likely fully decoded. As a result, it may or may not influence some real register. What it affects is undocumented, and likely changes from device to device, and even generation to generation of the same device.

Simply put, don't write to them, don't read from them. And don't worry "what's behind" them. There is no point in knowing, as what you "know" could change on the next rev of the silicon.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

If it's really true that Sim2 is based on the real chip models then one might be able observe the secondary effect of writing to reserved addresses. Though this is definitely nothing more than an intellectual exercise as no one would really go against the dire warning in the datasheet.

(I guess you could use it to obfuscate code for security purposes if such an odd thing were possible? - until the next rev of silicon broke the code that is!)

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

RES could use some registers of peripherals he does not use in this project.

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

Quote:

RES could use some registers of peripherals he does not use in this project.

Especially the ones between 0x00..0x3F (IO), 0x20..0x5F (RAM) as these can be accessed with SBI/CBI and make great bit vars. Often replacing eight uint8_t's at a time.

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

clawson wrote:

Especially the ones between 0x00..0x3F (IO), 0x20..0x5F (RAM) as these can be accessed with SBI/CBI and make great bit vars. Often replacing eight uint8_t's at a time.

Often???

A programmer of small embedded systems who cannot effectively use all the resources available - including bit variables, whether used through masks or through bitfields - deserves to run out of RAM soon.

If he has some sort of a higher education degree, he should also be subjected to public revocation of his diplomas.

JW

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

clawson wrote:

Especially the ones between 0x00..0x3F (IO), 0x20..0x5F (RAM) as these can be accessed with SBI/CBI and make great bit vars. Often replacing eight uint8_t's at a time.

Well for starters, SBI/CBI are only good for the range 0x00 and 0x1F [0-31]. After that any bit vars being poked in 0x20..0x5F are no different than using a single 8 bit var anywhere in RAM to hold 8 bit flags. [there is no need to use 8 separate uint8_t's] Simply use LDS/STS and SBR/CBR. [though there is a 1 cycle speed advantage of using the I/O registers from 0x20-0x3F since IN/OUT can be used to read/write them]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

glitch wrote:
reserved addresses are not likely fully decoded. As a result, it may or may not influence some real register. What it affects is undocumented, and likely changes from device to device, and even generation to generation of the same device.

Simply put, don't write to them, don't read from them. And don't worry "what's behind" them. There is no point in knowing, as what you "know" could change on the next rev of the silicon.

In some devices, not necessarily AVRs, some reserved addresses are used for factory test functions. They may do things like bypass a divider to speed up the testing of a Real Time Clock. Some data sheets even tell you that messing with "Reserved" addresses could cause physical damage to the part; a scary thought if you end up with a run away program during development.

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

Quote:

Well for starters, SBI/CBI are only good for the range 0x00 and 0x1F [0-31]. After that any bit vars being poked in 0x20..0x5F are no different than using a single 8 bit var anywhere in RAM to hold 8 bit flags.

glitch,

my bad, I meant 0x00..0x1F (IO) which is 0x20..0x3F (RAM)

Cliff