eeProm written to before getting past main()

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

Atmel studio, atmega64a, jtag. I read a uint16_t, increment, and write back to memory as a reboot count. The next time I reboot, 3 was added to my count. I now have a breakpoint set at main() and before code runs, eeProm memory has been incremented. I don't even get to the eeProm write and my memory changes. I set a breakpoint downstream where the eeProm write is and it never gets there. On top of that, if I comment out the eeProm write that I never get to, eeProm is no longer getting incremented. I thought code starts at main() but something else must be starting first and blowing past my eeProm breakpoint.

int main(void) {
	DDRA  |= (ledStop | ledStart | ledPwr | Piezo);						//PA enable output pins
	DDRB  |= (ledNetY | ledNetG | rlyWD | rlyDoor | rlyLamp | rlyPwr);	//PB enable output pins

Breakpoint highlighted. Memory has changed at this point.

 

	cntBoot = eeprom_read_word((uint16_t*) 80);				//get power loss count
	eeprom_write_word((uint16_t*) 80, cntBoot + 1);			        //update count and save

Breakpoint highlighted. Never get to this point but if I comment out the eeprom_write_word, the corruption stops.

 

eeprom 0x0050  09 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ..ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Highlighted write location

Sandy
Steril-Aire

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

Code may have been reordered by the optimser. What does the LSS say?

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

When you say "memory changes", which "memory"? Or, as in your first line, "read a uint16_t"; read where? A regular C variable or a quantity in EEPROM?

 

Same question about "I don't even get to the eeProm write and my memory changes"; again, which "memory" are you talking about, something in SRAM or in EEPROM?

 

Very likely, all this has something to do with optimization but with these cryptic snippets, its hard to even see what you are trying to do.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Hi Clawson

I just discovered it does it only under debug, stand alone is fine.

I turned of most of the optimizer off. I found this on line -g3 -gdwarf-2.

I have never looked at an lss file until just now. Not sure what to look for. I will sift through it.

Sandy
Steril-Aire

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

-Og  sets optimizer for best debug experience!

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

You must be a ham.

the memory I am concerned about is eeprom. I have moved the location of my eeprom around to confirm that something else wasn't writing over my data.

I am reading and writing a uint16_t to and from eeprom ad shown in the sample code given.

I tried several addresses in eeProm and all had the same issue.

The eeProm memory is changing even though I never get to the eeprom write routine.

 

In short, all I want to do is increment a 16 bit number in eeprom by one. Without doing any reads or writes, eeprom is incrementing by two. I am breaking on main(), first line of code. eeprom has changed. While I am at my breakpoint at main(), if I press ctrl+shift+f5 to restart debug, I break again at main() and eeprom has changed again although the program has not run.

Sandy
Steril-Aire

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

I have -Og set for optimizer and  -g3 -gdwarf-2 for debug.

Sandy
Steril-Aire

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

Interrupts enabled, but no ISR() handler???

 

Jim

Yes, there are several of us hanging around.

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Good thought, I fell into that trap once. I am breaking before ISR(s) are enabled. I also got rid of my debug string -g3 -gdwarf-2 with no change. The odd thing is it only happens when I start the debugger. If I am not running the debugger, all is well. Going home for the night. Thank guys.

Sandy
Steril-Aire

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

I think you are seeing the effect of the micro running your code for a short time as part of the debugger establishing a connection and the initialisation of the debug session.

 

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

Good morning N.Winterbottom

That kind of makes sense. In other words I think you are saying it is kind of running code without actually debugging. So, I think this might be a bug in Atmel Studio. I guess I will have to just put up with it until I am finished debugging.

I can see the boot count on my local display as well as in debug getting incremented 2 times. When not debugging, everything is fine.

Thanks for your input.

Sandy

 

 

Sandy
Steril-Aire

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

Sandy K. wrote:
You must be a ham.

You cannibal.

 

1.  Create a small and complete test program that demonstrates the situation.

1a.  If it doesn't occur with the small test program, then you are almost home.  Take the full app and cut back in chunks until...

1b.  Post that small complete program, along with the generated code.  (Hints indicate that it may be the .LSS file)

2.  Tell AVR model.

3.  Tell language/toolchain/version/optimization settings.

4.  Tell what you expect to happen.

5.  Tell what behaviour you >>are<< observing.

6.  Tell how you are testing and making the observations.

 

It in fact may be as simple as an uncaught ISR and the resultant race with/without the ICE running.

 

 

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

How big is your binary? Can you post the .lss file?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

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

Hi Theusch
I am under pressure so I will hack and slash later and try to narrow it down.

I put a break in the code before it even initializes and activates the ISR routines.

 

Hi Brian

The binary is 14k

Sandy
Steril-Aire

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

Sandy K. wrote:

Hi Brian

The binary is 14k

 

We've seen bigger.

 

Unless it contains trade secrets attach the .lss file to your next post.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

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

Thanks Brian

No trade secrets. Just do jaught to much at the coding.

Attachment(s): 

Sandy
Steril-Aire

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

Sandy K. wrote:
I put a break in the code before it even initializes and activates the ISR routines.

You aren't getting the whole point on the possibilities.  That's why I made the checklist; that's why others asked for the generated code.  The compiler may well re-order statements. 

 

IMO/IME, instead of declaring the emergency spend the time to consider and carry out the suggestions.

 

Hmmm--in "tell how you are testing", it will be interesting to learn how you are determining this possible fault.  Consider if you app ends up back at 0 somehow, and double-increments.  Same symptoms, right.

 

IME it may look like a daunting task to cut back, but often really isn't so bad -- in a big app I'd simply put in a dummy while(1) main loop and let essentially the entire app be unreachable code.  Given your description, that is what you are testing, right?

 

Many interesting scenarios come to mind.  Does the same thing happen in the simulator?  Does the same thing happen after an external reset as with a power-on cycle?  [e.g some type of rising power and then a dip cpould cause an apparent double-reset]  If you put a delay of say 100ms at the head of the code, do symptoms change?  What do you get when you step into the machine instructions vs. the first apparent C statement?  Is the brown-out detector enabled?

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: Wed. Jan 16, 2019 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Theusch

So far it is only associated with the starting or restarting debug. If I pull the power to my project and restart, the boot counter increments by 1 as it should. 

I put your little trap while(1) into my code starting at main(). I restarted debug and all is well. I started moving the trap further up the chain until I got to my eeprom write routine. As soon as I was downstream of the eeprom write, the issue was back. Interesting that break doesn't catch it but your line of code does.I will hack and slash later.

 

I am not up on the simulator, will the simulator save eeprom on a restart. What about the serial ports.

Sandy
Steril-Aire

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

Hmmm, the generated code looks OK after a quick glance. Certainly there's no re-ordering of instructions going on.

 

I wonder if this is a case of the breakpoints not lining up with the underlying code.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

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

Every time you exit the debugger it restarts the processor, adding one to your counter.

 

For example, the current value in the middle of a debug sessions is 13.  Quit the debugger, it reboots the processor and increments the counter to 14.  Then start another debug session and stop at the top of main and the counter now reads 15.  From the outside it looks like it jumped from 13 to 15.  It did - because of the extra reset when exiting the debugger and reentering.

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

Been tricked by that one before! Took me a little time to realise what was actually happening.

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

Thanks ScottMN

I thought it might be on exit but that makes total sense.

Thanks for everyone's help

Sandy

Sandy
Steril-Aire

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

Sandy K. wrote:
As soon as I was downstream of the eeprom write, the issue was back.

Did you try the steps that I outlined?  There is a reason for each step.  But if there is too much urgency, you may well spend longer being urgent than creating small test program; ...

 

 

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

Hi theusch

To make a long story short, no. I have been plowing through code. I get kind of focused and keep going. Your request has not fallen on deaf ears. I will get to it tomorrow.

Thank you

Sandy

Sandy
Steril-Aire

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

I stuck around and cut the entire project down to this. Ever time I restart debug, eeprom memory is increases by 3.

Good night

Sandy

 

uint16_t cntBoot = 0;								//power loss count

/************************************************************************/
/* initialize everything						*/
/************************************************************************/
int main(void) {

	cntBoot = eeprom_read_word((uint16_t*) 80);				//get reboot count
	eeprom_write_word((uint16_t*) 80, ++cntBoot);				//update count and save

	while(1) {}
}

 

Sandy
Steril-Aire

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

So the way to solve this is to only increment your count if it is a genuine reset. Luckily we can determine what caused your reset...

 

 

 

...so it looks like you can read this register and only do the increment if reset was caused by an external reset, or probably better not do the increment if it was a JTAG reset.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

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

Sandy K. wrote:
I stuck around and cut the entire project down to this.

But that isn't the complete program.  Also missing are the aforementioned toolchain/version/build options.  And still no .LSS.

 

Did you step into the binary, with e.g. breakpoint at 0?  Did you take a quick simulator run?

 

There is a purpose for these questions.  But I guess I need to leave things to the GCC gurus.

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

theusch wrote:

...And still no .LSS.

 

See post #16.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

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

Good morning Brian

I had the same thought around 1am to use MCUCSR flag. Been working on it. Unfortunately it is not the solution. I found that the JTRF flag is always set in debug, even if I pull the power and restart. If I use the JTRF to determine if I should increment the boot count, the count never advances, even if power is pulled. If I'm not in debug, everything works as expected. I tried a few power cycles and inspected MCUCSR flag. In debug I get 0x13, and a debug power reset I get an 0x11. It was a good thought.

Sandy
Steril-Aire

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

But isn't this now a "non-issue"? You already know that in the real world application of you device the boot counter IS going to work as intended.  I'm assuming that deployed units will not have debuggers attached?

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

Hi Clawson

I few messages back I discovered that the problem exists only in debug. In the real world it is not a problem. Everyone's help was appreciated but I don't think jumping through the hoops is needed. I looked at the MCUCSR flags to see if the debug issue could be resolved, and my conclusion is no.

 

For those of you who are interested, Not only did I include the *.LSS file this time but the entire cut down project. I used Atmel Studio and Atmel ICE.

Thank you all...Sandy

Attachment(s): 

Sandy
Steril-Aire

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

Brian Fairchild wrote:
See post #16.

...but not of the minimal program, which is not complete in its posting.  It is hard to play the home game without the magic decoder waller for the cluse.

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

Why not just put a short delay at the top of main while you're debugging?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Hi joeymorin

That sounds like a working solution. I could wait 500ms and then read/write to eeprom.

Thanks for the solution

Sandy

 

Sandy
Steril-Aire

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

Sandy K. wrote:
That sounds like a working solution. I could wait 500ms and then read/write to eeprom.
theusch wrote:
Many interesting scenarios come to mind. Does the same thing happen in the simulator? Does the same thing happen after an external reset as with a power-on cycle? [e.g some type of rising power and then a dip cpould cause an apparent double-reset] If you put a delay of say 100ms at the head of the code, do symptoms change? What do you get when you step into the machine instructions vs. the first apparent C statement? Is the brown-out detector enabled?

[IME that delay is generally standard practice.  It avoids much hair-pulling at startup with apps that might have bounces in power rise, or slow external devices such as character LCDs.  Did we ever hear about brown-out?]

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

Hi  theusch

As mentioned in #18, I am not familiar with the simulator. I am not sure how it will handle the eeprom simulation. I could probably try with the gutted code I posted and see what happens.

 

I don't have an external reset connected. Since it doesn't happen with a power cycle it probably worn't happen with an external reset. I can try. So far it only happens when starting debug.

 

The power supply I designed is fairly clean but since the problem doesn't occur on power up, it is a moot point.

 

Stepping in is an interesting point.

 

Brownout is enabled but since it is not power related...

 

Sandy
Steril-Aire

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

I have a home network with small RS485 nodes.

Power & data over a CAT-5 cable.

 

Every node sends a "hi" message when plugged on the cable.

I had problems with this setup, because the nodes often send garbage instead of an egligable message.

It turned out that the connectors have some intermittent contact before being fully & properly plugged in.

My simple solution was to simple start main() with a delay of half a second before doing anything else.

That is enough time for the connector to be fully plugged in.

 

How does your power supply voltage rise? If not monotonous, your CPU might brown out in between.

Brown-out should always be used when using EEProm.

 

If power supply for the debugger is taken from your target then it's power supply might dip below the brown-out threshhold when the debugger is connected and charging it's internal buffer caps.

 

You seem to be using C++.

C++ is always more complicated. Static classes are initialized (and their constructors called) before main( ).

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

Hi Paulvdh

In this case it is not a power issue. I don't cycle the power. It's when I start debug. When I go into debug, a register is incremented by 3. A break will not catch it. If I cycle power, the register is incremented by 1, as it should be. if you read the history, i think we have it figured. Some of the code is being run just before debug starts. The best solution was a 500ms delay before updating the register. Anyway at this point it is kind of a dead horse. It would be interesting to know if it is just Atmel Studio or if other programs have the same issue. Have a great weekend.

Sandy

Sandy
Steril-Aire