Expression evaluates as true?

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

Have a look at the screen shot below.

You can see the code has hit the breakpoint, and I'm not 100% sure why.

 

Screenshot of code and watches

 

I don't see how (0x000e >= 0x80) is evaluating as true?

 

 

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

Are you sure  size is set to 128? Try putting >=128 in your if statement & see if you get the same.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Thanks for the quick reply.

Here's the disassembly of the same function, showing the same breakpoint hit.

The loads at addresses 00000549 and 0000054A suggest it is definitely set to 0x0080.

 

You can also see the registers - they definitely seem to be 0x000e (R18:R19) and 0x0080 (R24:R25), and yet it steps into the body of the if() function?

It's not just debugger foolery/compiler optimisation either, because if I single-step then gsm_rx_pos becomes 0x007f as you'd expect.

 

 

**edit** spelling

SpiderKenny
@spiderelectron
www.spider-e.com

 

Last Edited: Fri. May 3, 2019 - 03:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"gsm_rx_pos"  I don't see this defined in your "task", so has it been defined as volatile? 

 

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

Ok I think I know what is going on here.

 

I think this is the watch window showing the wrong values. (or at least, wrong in time, not value).

 

In the disassembly (see below) where it is currently stopped at 0000055A it has just added "received" to "gsm_rx_pos", and then used the result in the compare (which is the IF in c), but it has not yet written this value back to gsm_rx_pos.

The watch window is showing the value from before the addittion.

Unfortunately at this step in the debugger "received" has been optimized away.

 

 

SpiderKenny
@spiderelectron
www.spider-e.com

 

Last Edited: Fri. May 3, 2019 - 03:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I generally stay away from stepping & debugger & use prints--then I avoid synchronization issues in such monitoring.  Of course, that is not the save-all in some cases (such as the delay/overhead in using prints causing side effects), or where there would be incessant printing.

 

Unfortunately at this step in the debugger "received" has been optimized away.

Some times you thank the compiler, some times you curse it.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. May 3, 2019 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure you are using -og optimization for debug! 

 

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

Thanks Jim for the optimizer tip. I will do that.

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

avrcandies wrote:
Some times you thank the compiler, some times you curse it.

So true!

 

Thanks for all the help.

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

Watch windows work best when the items in them are volatile.

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

Yea. Sometimes I move a local variable outside the function and set it volatile so I can see it in the debugger.

 

The compiler is sometimes more clever than the debugger, and both are usually better than me at keeping track of details.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

I like the interesting problems like this one. It made me think a bit harder and also it proved how useful the assembly listing can be too.

As that Australian (not Austrian) guy would say: "Its a trap for the young players".

SpiderKenny
@spiderelectron
www.spider-e.com