Program control gets messed up first function return when debugging

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

Attiny84, Atmel Ice, Studio 7, debugWire

 

WatchDog timer is NOT enabled.

 

Changed compile options to -O0 and -g3 (but I tried other -g and it didn't make a difference)

 

I've simplified the code to this:

 

void dummy()
{
    //downTime=millis();
    return;
    
}
int main(void)
{
    dummy();
    int b = checkButton();
    
    DDRA |= (1<<ENA_5V) | (1<<PINRED) | (1<<PINGREEN);
    ...

When I step through the return in the function dummy,  the program goes back to the first line of main.

 

It seems I can step through code without issue until the first return from function, even if there is nothing returned from the function.   Initially, I figured return of an unsigned long was the problem, but even with a void return, control goes back to the first line of main at the return.

 

I can avoid function calls, and run code that works fine.  

 

I've done lots of debugging with this Atmel Ice without seeing this issue.  

 

Maybe a bad processor or pcb?  But, it's virtually never the hardware...

 

It's like the compiler is confused about where the return address is saved on the stack? Or, the datatype returned is inconsistent with callers expectation.

 

I'm at a point where all I can think to do is remove the Attiny84 and try another, but I'm skeptical that will help.

 

Suggestions?

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

Post a complete program (project) so others can compile and troubleshoot, you have not provided enough info to answer your question!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

There's lots of other code that is never executed.   I attached a (main.c) but I think all but what I posted is irrelevant.

 

Do you want the .atlsn also?

 

 

Attachment(s): 

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

How to upload a .cproj file?  When I try to add as attachment, I'm told it's not a valid file type to upload.

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

It is always worth posting the complete project.   Or at least build-able code.

 

Source level debugging relies on attaching "Program Counter" addresses to each human statement.

 

If the Compiler has rearranged the code or simply optimised the performance you find unexpected behaviour.

You can force some correspondence by adding asm("nop") lines in unnecessary places.

 

This enables you to place Breakpoints that would otherwise never have a "PC" address.

 

If in doubt,   step through the mixed Disassambly/Source Code view.

And learn that some lines are best avoided for Breakpoints.

 

David.

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

That code looks like a possibly heavy candidate for aggressive optimisation. For example the compiler will either (a) inline dummy() or possibly even (b) see dummy() does nothing so ditch it completely. The same may be true for b = checkButton(). If it determines that 'b' is never subsequently used it might ditch the entire thing too - no point wasting time to create something that is never used.

 

Like others I'd like to see a .zip of a complete AS7 project we can all build locally and study the LSS etc.

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

Again, only the first line of main.c gets executed, the dummy function call is made, the return is back to the first line of main.  It loops forever making the function call to dummy and returning.

 

I'm quite familiar with debug confusion due to optimization, but something else is going on.   Also, please note -O0 and -g3.

 

I'll start a completely new project with nothing but the code I posted in the first note.  If the problem goes away, I'll add code until I see the problem.

 

If I still see the same symptom in the new project, I'll post the project.

 

Thanks for the quick replies--I didn't really expect any so soon.  It will be this evening before I can work more on this.

 

Thanks!

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

I compiled your code ok (using ICC), verify you are compiling for the correct AVR (tiny84) and/or follow the suggestions above.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

I have seen behavior that is generally like what was described in the initial post. In the process of debugging the strangely executing code, I discovered that it really WAS doing those other tasks, but that they were inlined, so you would not see their execution in the hardware debugger.

 

Suggestion: look at it in the disassembled form. Bet you will see that those other tasks ARE being executed. That I how I discovered how my code was being executed, even though it did not appear to be happening.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

No, it's not the typical optimization confusion.  I can (step into F11) under disassembly view and see the same thing.  The ret instruction causes execution to start again at the first line of main.

 

New project from scratch, same symptom.  Yes, attiny84 is device chosen.

 

I added a line of code to illuminate and LED by driving a pin low.  That line executes if no function calls are made (I just comment out the dummy() call) but execution just returns to the first line of main if any function call is made

 

Same thing when not debugging.  A return from any function returns execution to the first line of main.

 

Pretty much has to be hardware, I think.  Perhaps it could be the ICE, not sure.

 

zip file attached.

 

Attachment(s): 

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

This sounds a lot like an unhooked interrupt and the _bad_interrupt handler to me.

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

Interrupts aren't enabled--aren't they disabled by default?

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

I just loaded you GccApllication1 into AS7 and changed nothing except to set the debugger to be "Simulator" instead of DebugWire+T84 (I don't have a tiny 84) then I built/simulated it and it works just fine. The steps into/out of dummy() work just as expected then it does on to the other DDR lines etc.

 

Conclusion - dodgy debugWire !

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

Thanks for taking the trouble to do that.

 

I was thinking that too--I had issues (not quite like this) with debugWire.  But they seemed to go away when I threw away the dragon and started using the AtmelIce.

 

But, I went out of debugWire and ran the program.  With the call to dummy() commented, the LED illuminates.  Without it, it does not.

 

I think next step is change the attiny.  Don't know what else to do.

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

Replaced the Attiny84 and all is well.

 

I should have done that earlier, but several times in the past I've replaced a processor only to find the issue was not eliminated.  

 

Actually, I think this might be the first time of what must be around 100 Atmel projects where I've isolated a problem to a defective processor.  Several 1st pass pcb design issues or poor solder reflow, but never simply a bad processor.

 

(I did add solder to all the processor pads and retesting before replacing the processor)

 

Also, it's an interesting failure symptom.  It can be programmed and executes ok until a function return.  Didn't seem likely to be a hardware issue.  

 

Sorry to bother and thanks for your attention.

 

 

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

Wonder who scored #13 with 1 star ??

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

I am sceptical.   In my experience Silicon works when fresh out of the box.   (failed QC should never leave the factory)

 

Unless you deliberately release smoke from the Silicon it will continue to work 100% for years.

 

Yes,  I wore out some Flash pages on an AVR with excessive SPM.

Yes,  30-40 years ago RAM memory chips were not very reliable.

 

It is quite possible that a healthy Tiny84 has died by itself.    Even if it has never been stressed beyond the datasheet spec.

 

David.

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

David Prentice yes, I agree.  I'd add, that most silicon failures are are a result of bad card design--not adhering to a safe operating conditions.  That's why I wasted so much time before I changed it.

 

Furthermore, I can't think of how the processor could be stressed to have it fail this way.  

 

As far as one star--

 

I really hesitated to post at all because I knew everyone would assume I was  newbie and was being confused by optimized execution flow when single stepping under a debugger.  I probably would make the same suggestion, but I tried to avoid going there  by emphasizing that I'd compiled with optimization turned off and that execution flow returned to the first line of main.

 

I spent a few years of my career writing debuggers for IBM's "unix like OS" (aix) and kernel debuggers, so I'm quite familiar with optimization "bugs" (not really bugs).

 

I spent some time hacking/whacking down the code so execution control was messed up on the first line of main, calling a function that simply returned.  So, it was obvious that readers assumed I was "just another idiot" when they was asked to post the entire project.

 

Should I award stars for that?

 

I award stars when I find the replies helpful.  Clawson's reply was helpful in hindsight--at the time I was assuming the issue was my AtmelIce, so I hadn't tried running under the simulator.  (I assumed all would be fine when running under a simulator).  But, if I'd done that, perhaps readers wouldn't just assume it was an optimization confusion issue.

 

So, that's why I awarded one star for that.  I learned I should do that if/when I'm thinking my issue must be hardware.

 

Are there guidelines on awarding stars?  I've been around on this forum for years, and if I ever read about that, I've long since forgotten.

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

Post #13 was suggesting flaky hardware.

 

The problem WAS flaky hardware.

 

Still don't see why a post that leads to the solution is marked down but to be honest I don't actually care what you think.

 

I was just interested to know who was so misguided as to mark it down. Now I know.

 

I must say I am so thankful I spent the time to download your GCCApplication1.zip, load it, modify it and simulate it to try and guide you to a solution. I'm guessing that is 5 wasted minutes of my life I'll never be getting back.

 

Makes you wonder whether it's worth bothering trying to help at all.

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

SORRY!

 

I though I was doing something positive my marking one star.  That was my intent  Why is that marking it down?

 

I'm confused.

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

Posted : Wed. Jan 9, 2019 - 01:02 PM 

You voted 1. Total votes: 1

 

Are you saying I should have clicked on 4 stars instead?

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

If someone asks you to review a book with the option of 1..5 stars don't you read that as

 

1 - utter rubbish, would avoid this like the plague

2 - quite poor, probably not worth wasting your time

3 - no strong opinion - make up your own mind

4 - interesting but not the best thing I ever read

5 - outstanding, everyone should read this book

 

That's certainly how I interpret the stars on my Kindle so I tend to read the stars here in the same way. YMMV.

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

Clawson,

 

I guess I'm clueless about proper etiquette on this forum.  I'm really sorry to offended you.  You've been really helpful in numerous past posts, and honestly, when I posted I was specifically hoping you'd still be around and respond.

 

It obviously costs me nothing to click on more stars.  So, now that I know anyone really cares, I'll click on all four if something's helpful.  

 

I didn't click on "Solution", since you said:

 

Conclusion - dodgy debugWire !

Sure, that's "hardware" and if the problem went away after programming with ISP, I'd have marked that as a solution.  But, the problem occurred whether debugging or not, and it required change of the Attiny84 to resolve.  

 

 

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

Here's what I was thinking when I awarded one star (I've since changed it to 5).

 

No stars --  not helpful

 

1 star     --  helpful

2 stars   --  helpful, and required some experience or insight I didn't have

3 stars   --  Same as 2 but requiring more effort to respond

4 stars   --  Same effort but something that's a show stopper problem for me.  Something that I couldn't solve at all without help.  Versus something where I think I quick reply from the forum could save me a few hours.  

5 stars   --  Lots of work to respond, may posts on the thread.  Try this, that didn't work, try that.  Lots of replies required on the thread.

 

In this specific case, a simple "have you tried running under the simulator" response would have been more helpful.  But, of course, that's hindsight.

 

    

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

Sorry Dave - I guess this stems from our different interpretation of stars (AFAIK no one has ever said how they should be used in fact) so sorry about that. blush

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

Thank you for always seeming to be on the forum and responding so quickly!

Last Edited: Thu. Jan 10, 2019 - 04:33 PM