-O0 can't set breakpoint even at asm volatile ("nop&quo

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

user level: newbie +idiot
studio 4.14 build 589
WinAVR-20080610\bin\avr-gcc.exe
Jtag cable II

Hi need some direction on this:

optimization level -O0

Was debugging code fine then at some point I noticed that the code would start simulating several lines down from the beginning. I have attached a screenshot. The yellow arrow shoes where the debug starts after I hit "RUN" button.

I see that the previous port on,off instructions are missing in the dissasembler view. As if they were optimized out... HOWEVER , when I hit run the target DOES execute the code above the yellow arrow....(Leds blink twice- not just once)

Can not set a breakpoint at the first PORTC=0XFE; (of course)

There are many other areas of code where I have inserted asm volatile ("nops") , to try to troubleshoot this, but I can't even set a breakpoint on those....

An idiots summary: It seems that some code is not recognized by the debugger but it is actually being run...why?

any ideas where to start with this?
thanks in advance ;-)
[img]http://www.flickr.com/photos/284...@N08/6501578757/[img]

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

Well I was going to say you should take a look at:

Optimization and the importance of volatile in GCC

but this should not apply when -O0 is being used. From the picture it does look like the debugger may be counting source file lines wrong which might be a problem with a mixture of \n and \r\n terminated lines in the source - but this is a very outside possibility.

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

yes, i am familiar with "Optimization and the importance of volatile in GCC " ,but it should't matter with -O0 and it should never be able to optimize out setting a PORT, correct?

Plus the target actually performs the "optimized out part".

It was strange as after a "rebuild all" it suddenly started the strange behavior, i back-deleted the code (i think) to where i was before the problem and still the strange behavior.

Maybe something in WINAVR got corrupted? (remember i don't know much)

I'm working on a different project (until I figure this out) that uses ISP instead of Jtag and will see if I have similiar problems. I'll also try working on some other JTAG projects to see what happens then.

I'm too ignorant to know what "problem with a mixture of \n and \r\n terminated lines in the source" might mean, and maybe to ignorant to know what to do with that info if I did.

SHould I possibly try to re-install WINAVR?

Thanks for the advice.

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

Quote:
uses ISP instead of Jtag
Do you mean debugWire instead of JTAG?

edit also

Quote:
studio 4.14 build 589
WinAVR-20080610\bin\avr-gcc.exe
Pretty old and some of the earlier studio 4 versions may have had some strange bugs...unlike say Studio 5 which IS a bug... :? so you may want to try your hand with Studio 4.19 and winAvr 20100110.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

debugwire? I'm using avr studio4 and as platform I've selected AVR simulator. Then I hit debug....is that debugwire? (not trying to be sarcastic, i just don't know)

More .... So this is a different project in studio4, simulating with simulator NOT Jtag this time. -0O

After the line : volatile int volts_byte=155; // REMOVE
the watch for volts_byte=155 [OK!]
Then if I step into :voltage_to_afr(volts_byte); // volt

I get the screenshot attached. This is BEFORE any of the formulas in that function are even reached!....????????

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

Quote:
debugwire? I'm using avr studio4 and as platform I've selected AVR simulator.
debugWire is another HARDWARE debug interface similar to JTAG but using only the reset line in smaller chips. You said "uses ISP instead of Jtag" so I thought you meant debugWire as it uses one of the pins used by the ISP interface. You can ONLY program with ISP, no debug facilities.

If you are using the simulator, perticularly THAT OLD, you may be asking for troubles.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

ok, will update studio4 (stay away from 5 still?) and winavr.

Briefly , will it automatically keep all my old projects during the upgrade?

thanks again i will report back

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

Quote:
will it automatically keep all my old projects during the upgrade?
Yes.
When you say "Jtag cable II " I'm guessing it's the one from Propox?? If so it is not a JTAG Mk2 but in fact a JTAG Mk1 (as far as Studio is concerned) and it will only support a limited number of older chips. Which chip are you using by the way?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Quote:
will it automatically keep all my old projects during the upgrade?
Yes.
When you say "Jtag cable II " I'm guessing it's the one from Propox?? If so it is not a JTAG Mk2 but in fact a JTAG Mk1 (as far as Studio is concerned) and it will only support a limited number of older chips. Which chip are you using by the way?

atmega128 for the Jtag question, and yes propox cable, let's forget about the AVR Simulator (atmega328p) example ,for a while, it might confuse things.

I installed the latest 4.19 Studio4 build and newer WINAVR, I will test the original problem and report back. Thanks for your help so far.

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

STOP XMASS!!! (joking)

Ok it seems that what is going on is "just" that the yellow arrow in the studio4 view of my source file is being placed several lines farther "down" than where it actually is (compared to how the target is behaving). The arrow is on the correct instructions when looking at the dissasembler view but not when looking at the source view.........any clues as to what I did wrong? Clawson you mentioned it might have something to do with line terminations......i'll have to look into that. I'm not sure exactly what you mean...yet.

AFAIK it is only doing it on this particular source file & regardless of which version of studio4 or winavr ..is their some "invisible" instructions i have typed or......???

And before I forget have a good holiday!!

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

Merry xmass to me!

I figured out the problem.

I opened up my C source file in Notepad++ and converted it to Unix END-of-Line. Now it works, I'm not sure what happened to cause this originally, possibly I opened up the file earlier and converted it out of Unix...I have no idea. At least I learned alot of things, before figuring this out....all part of the process. Thnaks and hope this helps someone.

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

It's strange I went through my studio4 projects and opened up some .c files in noteped++ and they all are in windows format (not unix), so I don't know...really what happened.

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

I did say:

Quote:

From the picture it does look like the debugger may be counting source file lines wrong which might be a problem with a mixture of \n and \r\n terminated lines in the source -

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

Clawson: yup and I gave you credit for it several posts up! ;-)

Can you school me on how that may have happened, I know little about that type of thing.

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

Quote:

Can you school me on how that may have happened, I know little about that type of thing.

You used two different editors at different times. Some editors only edit the lines you actually insert/change so may put their own line terminator on them while the existing lines are just copied verbatim (with different line endings) from input to output file.

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

thanks Clawson, i'll be more careful with that.