SRAM erased during serial programming

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

I would like to revive this post, which didn't seem to reach a conclusion: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=123120&start=0&postdays=0&postorder=asc&highlight=

I've made a simple battery powered device with a tiny861A, which is supposed to run for months "“ maybe even years. Now, I was hoping that I could make a firmware upgrade without losing the contents of certain variables. These variables are defined in a struct, which is placed in the .noinit section. To make room for future "ordinary" variables, I told the linker to place the .noinit section on fixed address somewhat higher than the common memory area.

LDFLAGS += -Wl,--section-start=.noinit=0x8000E0

Now, this (almost) works nicely. I can make a hard reset, and the .noinit variable contents are intact. But after serial programming with an AVRISPmkII (hex file only), the SRAM seems to be cleared. All zeros, that is.

I tried different base addresses for .noinit, and also tried removing the mentioned LDFLAGS line, but none of it made any difference.

Neither the datasheet, nor the application notes I've searched through, mention anything about what happens to SRAM during serial programming.

Is what I'm trying to do just plain impossible? Anybody?

Br, E

You're absolutely right. This member is stupid. Please help.

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

Isn't it amazing, how just posting a question can sometimes create new ideas in the OP's mind?

I experimented a bit more, and it seems that the chip erase command does indeed clear the SRAM. Turn chip erase off – and firmware upload no longer messes the SRAM up. But then again, firmware upload is rather useless without chip erase. :roll:

I believe this is an undocumented chip feature (or maybe chip annoyance).

Br, E

You're absolutely right. This member is stupid. Please help.

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

It would never cross my mind to keep SRAM during ISP.

However, you can obviously use SPM from a running application. This is normally referred to as IAP (in application programming).

IAP is a lot more complex than using ISP with an AVRISP-2. If you want to keep things simple, put your important variables in EEPROM and set the EESAVE fuse.

David.

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

On the other hand.
if you do not use chip erase then all that does is not first clear the entire chip before you write the new blocks of data to it. worst thing that could happen I guess it that when your new file is smaller then the old one code is still in place. I wonder what would happen if you make a hex file the exact size of the Flash and program that.
If that works, all you need to do is make sure the hex file is maxed-out.

on the other hand, is there not a way to use the EEPRom? add some code that you tell to the chip you are going to reprogram and then after reprogramming fetch the variables back from the eeprom and keep on running.
you could even implement a check that when a certain eeprom field does not have a specific number that then the content is corrupt and should not be used.

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

meslomp wrote:
On the other hand.
if you do not use chip erase then all that does is not first clear the entire chip before you write the new blocks of data to it. worst thing that could happen I guess it that when your new file is smaller then the old one code is still in place.
???
He's talking about ISP. You can't erase single pages through ISP, so how should that work?

Stefan Ernst

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

Quote:
He's talking about ISP. You can't erase single pages through ISP, so how should that work?

True. I actually tried it – just changed the firmware version number, compiled, and uploaded. As expected, the new program was ANDed on top of the old one. So in case of ISP, chip erase is a necessity.

Yeah, the EEPROM seems to be the only practical solution. I don't have a communication port (unless you'd call a display and a knob a "communication port"), so a bootloader is out of the question.

Quote:
It would never cross my mind to keep SRAM during ISP.

No, I admit that the idea is unusual. But unless the chip erase actually uses SRAM for something (can't imagine what), I don't see any reason for clearing it. Unless you've filled the SRAM almost beyond capacity, it is quite easy to have your noinit variables placed in the same location from firmware to firmware. And with some dicipline, you can make a new firmware which can take over from the old one without much hassle.

Unorthodox? Probably. But I'm not a religious guy. :wink:

You're absolutely right. This member is stupid. Please help.

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

I haven't fully thought this through but...

could you have a bit of code, in the bootloader area, that used IAP to rewrite the application area to 0xFF? Run it via your display and knob before your ISP operation. ISP should then work as the flash would be blank.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

ErikT wrote:
But unless the chip erase actually uses SRAM for something (can't imagine what), I don't see any reason for clearing it.
For security reasons. Otherwise you could easily get the runtime data of any application, and that could include keys and the like.

Stefan Ernst

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

Quote:
For security reasons. Otherwise you could easily get the runtime data of any application, and that could include keys and the like.

True. Hadn't thought about that one. Would have expected Atmel to write something about that in the datasheet, though.
Quote:
could you have a bit of code, in the bootloader area, that used IAP to rewrite the application area to 0xFF? Run it via your display and knob before your ISP operation. ISP should then work as the flash would be blank.

Yeah, that would work. But, given the choice, I think the EEPROM solution would be easier.

Thank you for your inputs, guys. Always enlightening to hear (or read) other people's ideas and views on things.

Br, E

You're absolutely right. This member is stupid. Please help.

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

sternst wrote:
Otherwise you could easily get the runtime data of any application,

Could you tell me how you would do that ?

My Mega32 only seems to have ISP commands to read & write the program and EEPROM, not the SRAM.

And yes, I'm serious. Reading & writing SRAM using nothing else than a standard ISP connection would be helpful to me.

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

Quote:

Reading & writing SRAM using nothing else than a standard ISP connection would be helpful to me.

You do know that you could use JTAG don't you? It can do everything that ISP allows and also gives you easy access to reading/writing SRAM (and SFR IOs etc).

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

Nestor wrote:
sternst wrote:
Otherwise you could easily get the runtime data of any application,

Could you tell me how you would do that ?
By flashing an application that "exports" the RAM content (e.g. with UART).

Stefan Ernst

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

Quote:
For security reasons. Otherwise you could easily get the runtime data of any application, and that could include keys and the like.

Haven't really thought enough on this, but couldn't you just attach a JTAG dongle and read out the RAM? The JTAG will do a reset, but that in itself would not reset RAM if you can just stop the app from restarting and clearing (parts of) the RAM (e.g. as done by C startup code).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
Quote:
For security reasons. Otherwise you could easily get the runtime data of any application, and that could include keys and the like.

Haven't really thought enough on this, but couldn't you just attach a JTAG dongle and read out the RAM?
And how do you enable JTAG?

Stefan Ernst

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

clawson wrote:
You do know that you could use JTAG don't you?
Ah. I forgot all about JTAG.

But alas, I do not have JTAG hardware available, just ISP.