ATmega 328p Cheap Debugger

Go To Last Post
98 posts / 0 new

Pages

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

anto1 wrote:
of course.

Remember that we can't see your screen, and we can't see what you're doing - so your descriptions need to be precise and complete.

anto1 wrote:
awneil wrote:

Do you really mean "disappeared", or just greyed-out (ie, disabled)?

of course greyed

"Greyed-out" is very different from "disappeared".

 

Screenshots can help (some tips on doing screenshots in Tip #1 in my signature, below).

 

EDIT

 

See #55 - I had to switch computers to find a working simulator...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 12:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I am confused. Admittedly we don't have access to anto1's code except via the updated project that David posted in #46 but when I load that into Studio 7 and go to the lines shown in #30 this is what happens for me...

 

 

I have done nothing more than loading the project and building it. I haven't even started to try and debug/simulate but when I do those lines remain in exactly the same state and the simulator starts here:

 

 

So everything "just works" doesn't it? Where exactly is the problem in any of this ?

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

david.prentice wrote:

making code "Simulator-friendly"

anto1 wrote:
thanx for ur answer, but i'm not clear what does it mean?

 

It means adapting the code so that it can easily be run & debugged in the Simulator.

 

eg,

in #29, ki0bk wrote:
Delays in the simulator are Veeeeeeerrrrrrrryyyyyy slow, most freaks will either comment out delays, or shorten them

 

eg,

#if defined SIMULATOR
// short delays when running in simulator
#define DELAY_VALUE_1   1
#define DELAY_VALUE_2   2
#define DELAY_VALUE_3   3
#else
// normal delays when running in real hardware
#define DELAY_VALUE_1   1000
#define DELAY_VALUE_1   2000
#define DELAY_VALUE_1   3000
#endif

(not sure if a factor of 1000 is going to be enough?)

 

And, in the simulator, you don't have any of the external hardware - so you'll need to adapt any parts that rely upon interaction with external hardware.

 

 

EDIT

 

Maybe a more manageable approach to the delays would be something like:

// A scaling factor to allow for the fact that delays in the Simulator are far slower than in the real hardware
#if defined SIMULATOR
// short delays when running in simulator 
#define DELAY_FACTOR 1
#else
// normal delays when running in real hardware
#define DELAY_FACTOR 1000
#endif 

// Now the actual delay values
#define DELAY_VALUE_1 (1 * DELAY_FACTOR)
#define DELAY_VALUE_2 (2 * DELAY_FACTOR) 
#define DELAY_VALUE_3 (3 * DELAY_FACTOR)

(again, the factor may need adjustment)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 11:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

awneil wrote:

which button, exactly, are you calling the "debugging button" here?

anto1 wrote:
i mean the start debugging of course.

It's not "of course" - there are two buttons available to start debugging:

 

 

  •  = Start Debugging & Break
  •  = Start debugging

 

 

If you use 'Start Debugging', then it starts with the simulation running - so it is to be expected that the stepping buttons will be greyed-out:

 

 

 If you use 'Start Debugging & Break', then it starts the simulation and immediately halts at the first line in main() - in this case, the stepping buttons will be active:

 

EDIT

 

Updated 2nd screenshot

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 12:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
And, in the simulator, you don't have any of the external hardware

 

if it has hardware, for example thermo sensor by 1-Wire interface, what is my actions?

to comment this part of code or something else?

atmega328p

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

This is not really specific to AVR or Microchip Studio.

 

Some common options include

  • you make your temperature sensor stuff return some dummy values;
  • you manually enter a value when required

 

I've never used it, but I think the Simulator support "Stimulus files" - which let you supply values to the simulator.

 

A key thing is to have your code nicely modular/layered - so you can easily isolate the hardware-dependent bits from the hardware-independent bits.

 

Then you could easily do things like running the hardware-independent code on a PC, and supply inputs via files, user console, test harness, etc ...

 

EDIT

 

eg (pseudocode),

int temperature_read( void );
{
    int temperature_value;
    
#if SIMLATOR
    // Simulator - read from file
    fread( temperature_file, &temperature_value );
#else
    // Real hardware - read from 1-Wire
    one_wire_read( &temperature_value );
#endif

    return temperature_value;
}

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 01:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Simulator is purely for testing the code that supports "internal" peripherals (timers being the classic example) as soon as you cross the boundary to "outside" the chip (ADC readings, UART/SPI/I2C traffic etc) things get much trickier for simulation alone. Possible options are

 

1) explore the use of the Studio simulator's "stimuli" files. You can effectively write "scripts" that say things like "at this moment pin B5 changed from high to low" or 'at this point in time ADC read 0x3B7". But trying to simulate an entire 1-wire dialog in such a way is probably going to be more complex than writing the 1-wire code in the first place

 

2) either use an Eval copy or pay the €300+ for a copy of the Proteus VSM simulator. The reason it costs so much money is that the clever people at LabCenter really have created simulations of "outside" devices like serial terminals, LCD displays, UART/SPI/I2C devices and possibly even some 1-wire devices

 

3) get an OCD interface (debugWire/JTAG/PDI/etc) to sit between your PC and a real AVR circuit. The experience will be very similar to using the simulator except that the devices outside the chip really will operate as intended (because it's the "real" chips. 

 

4) use real hardware but do the debugging with other diagnostic devices like logic probes, logic analysers and oscilloscopes

 

For something like 1-wire I'd say only (3) and (4) were viable options.

 

PS there is a (5) and that's also to use real hardware but if you don't have diagnostic tools like OCD/analyser)/scope get the code inside the AVR to tell you what is going on by outputs such as LCD, UART to a serial terminal or even just flashing LEDs to give an idea of where it's getting to and what state it is in. 

Last Edited: Mon. Jan 10, 2022 - 01:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


clawson wrote:
I am confused.

Likewise.

 

I see the same as you - and the Simulator even allows me to set & clear breakpoints while it's running.

 

I rarely ever use the Simulator, but I've certainly seen with real hardware that it can get stuck with these "ghost" breakpoints:

 

In this case, "turning it off and on again" seems to be the answer (this includes 'Delete All Breakpoints', a clean & rebuild, and reprogramming the chip)

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I made some suggestions in #46.   If you "tidy up" your project,  readers will be more inclined to help.

 

It is often a good idea to learn with a "useful project".   You know how you want it to behave.   You will notice when something is wrong.

You can describe the problem in English.

 

I suspect that you have taken a working project from somewhere and are trying to adapt it.

It is often wiser to just post a link to the original working project.    Describe your "similar" hardware.   Ask for help.

 

However it might be better to start with simple projects.   Learn how to write C code.  Learn how to use the Simulator (and/or the Hardware Debugger).

 

David.

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

awneil wrote:
If you use 'Start Debugging', then it starts with the simulation running - so it is to be expected that the stepping buttons will be greyed-out:

thanx so much! i pressed this button before F5.

awneil wrote:

 

 If you use 'Start Debugging & Break', then it starts the simulation and immediately halts at the first line in main() - in this case, the stepping buttons will be active:

and now while i pressed this button Alt-F5 and the handles didnot grayed, but the breakpoint becomes white (not red, as it must be) and the pointer drop  to

the assembly window, it has opened by auto, even i had closed it , after alt-f5 it becomes opened.

but i had tried very accurate folowig by the simulator manual

AVR-Simulator-UserGuide-DS50003042A.pdf

because as u know, atmel has included to the microchip and all the site was changed.

Attachment(s): 

atmega328p

Last Edited: Mon. Jan 10, 2022 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

anto1 wrote:
and the pointer drop  to the assembly window

That's often a sign that the code you're executing is out-of-step with the source code.

 

EDIT: See #36

 

That's telling you that it can't find any source file which corresponds to the current PC location.

 

the breakpoint becomes white (not red

See #59

 

EDIT

 

anto1 wrote:
AVR-Simulator-UserGuide-DS50003042A.pdf

You mean this: https://www.microchip.com/content/dam/mchp/documents/parked-documents/AVR-Simulator-UserGuide-DS50003042A.pdf ?

 

See also: https://onlinedocs.microchip.com... - note that this comes complete with source code for you to follow along with

 

And, of course, those 'Getting Started' tutorial videos ...

 

eg, Getting Started with Atmel Studio 7 - Episode 12 - AVR® MCU Simulator Debugging: https://www.youtube.com/watch?v=...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
That's telling you that it can't find any source file which corresponds to the current PC location.
And that is because that particular piece of code (where it's doing the LPMs) is known as the "C Run Time" (CRT) which is the bit of "start up" code that comes with the compiler and gets built into the programs you create. Some parts of it will be part of every program you write (unless you use the -nostartfiles option) but some bits only get added as soon as you start to create global variables. if you have any that are created with initial values (so called ".data variables") then the linker adds a piece of code called __do_copy_data and that is the code shown in the picture. If you add global variables but that are not given an initial value (so called ".bss variables") then the linker adds a different piece of code (__do_clear_bss) which is code that simply ensures they meet the promise of the C language to start with 0 in them.

 

When I built David's version of your project the .map file contained:

c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_copy_data.o)
                              main.o (__do_copy_data)
c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_clear_bss.o)
                              main.o (__do_clear_bss)

showing that these two pieces of code are contained in a library called libgcc.a. You can see they are built into your program later on:

 *(.init4)
 .init4         0x00000074       0x16 c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_copy_data.o)
                0x00000074                __do_copy_data
 .init4         0x0000008a       0x10 c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_clear_bss.o)
                0x0000008a                __do_clear_bss

The code in libgcc.a comes a binary only, there is no source for it (well not on your computer anyway) so that is why the debugger says "no source file".

 

Note in the .map file that pretty much anything in *(.initN) is part of the CRT.

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

 

awneil wrote:
I rarely ever use the Simulator, but I've certainly seen with real hardware that it can get stuck with these "ghost" breakpoints:

 

In this case, "turning it off and on again" seems to be the answer (this includes 'Delete All Breakpoints', a clean & rebuild, and reprogramming the chip)

 

Found this in another thread:

meolsen (a Microchip insider) wrote:
Breakpoints are generally saved to the *suo file in the project, but this does not happen i real time (i.e if there's a crash it could become invalid

 

https://www.avrfreaks.net/commen...

 

So it might also be worth deleting the  .atsuo file:

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 10, 2022 - 03:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If you add global variables but that are not given an initial value

 

when i declare any variable, global or even local, it always are initialized. as u can see in my code sample.

 

clawson wrote:
there is no source for it (well not on your computer anyway) so that is why the debugger says "no source file"

 

what does it mean, i'm not clear? that my copy of A S doesn't full installed ? Because if the other users hasn't such an error, while my code sample running?

 

would u like to advice me, please, which actions i need 2 do for this artefact removing?

 

 

 

atmega328p

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

 

just double sended message

 

atmega328p

Last Edited: Tue. Jan 11, 2022 - 06:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

So it might also be worth deleting the  .atsuo file:

 

i had deleted this file, then i had add the new breakpoints, then preSsed alt-F5 but with the same success, as in my screenshot above -

it has dropped to assembly window and breakpoints becomes white.  the pointer moved by the lines, but by assembler code.

 

by the other hand, u and other users does't  not usually remove the .atsuo file, so may be i need to check some

settings in my project ? or compare, are my settings equal to ur settings? (if u can run my code sample for debugging w/o err.messages, of coarse.)

atmega328p

Last Edited: Tue. Jan 11, 2022 - 08:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


anto1 wrote:
what does it mean, i'm not clear? that my copy of A S doesn't full installed ? Because if the other users hasn't such an error, while my code sample running?
The toolchain that comes with Studio 7 is effectively in 4 parts. There is a compiler/preprocessor from the GNU Compiler Collection, there is an AVR assembler, linker and other utilities from GNU "Binutils" (binary utilities). There is a prebuilt copy of AVR-Libc that has stuff (built specifically for AVR) like memcpy, printf, sin, cos, tan and so on. Then there are the prebuilt "GCC libraries". That fourth part is:

 

 

Now there are different "families" (architectures) of AVR. The real small tiny ones for example don't support instructions like CALL, JMP (they have only RJMP and RCALL) and they don't have a multiplier so there is no MUL instruction. At the other end of the scale you have (>= 256K) mega and xmega chips that not only have CALL/JMP but things like ELPM and the CALL for example pushes 3 bytes not 2 bytes on the stack to allow for returns outside of the 128K code that 16 bits can reach. Because of all this the same code (of which this is just part):

 

https://github.com/gcc-mirror/gc...

 

is built about 18 times so you then have:

 

 

so for each architecture variant there are copies of libgcc and libgcov built. On the whole you can ignore libgcov as it is for a very specialist purpose and almost never used. But the point is that there are about 18 different copies of libgcc.a built when the guy who builds and distributes the compiler (Microchip in the case of the toolchain in Studio 7) actually builds the compiler and tools from their source code.

 

Now when you build your 328P project the compiler driver (avr-gcc) knows from the -mmcu= value passed during the build that atmega328P is actually AVR architecture "avr5". You can tell that from the .map file that the linker creates:

c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_copy_data.o)
                              main.o (__do_copy_data)
c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/avr5\libgcc.a(_clear_bss.o)
                              main.o (__do_clear_bss)

So it is this copy of libgcc.a that is "linked" with programs that you build:

 

 

Now binutils comes with a whole load of tools. I already mentioned the assembler (avr-as) and the linker (avr-ld) but there are other tools such as avr-nm that you can use to "look inside" library archive files (.a files). So you can see what libgcc.a contains:

 

 

So a .a file is made up of a whole collection of .o (object) files that are each in ELF format (that is pre-built binary with symbols). The " T " entries in each effectively tell you what function names the files provide. On the whole it is just one function per file (because as soon as you link one function from a .o file in a .a archive you get ALL the functions in that file).

 

Further down that output you will find the entries that provide __do_copy_data and __do_clear_bss:

 

 

Now if I build the very simplest of C programs:

 

 

That is a program with a global, initialised variable. Then after -save-temps the assembler source that this generates:

 

 

ends with:

 

 

That one ".global" alone is enough instruction to the linker to say "when you link this, which will include you linking against files such as libc.a, libm.a and libgcc.a see if you can find a function called __do_copy_data() and, if you can, add its code to the program you are building".

 

By the same token if my program had .bss variables rather than .data variables it would be:

 

 

then:

 

 

You can see the actual code of __do_copy_data or __do_clear_bss in the libgcc.a with "avr-objdump -S libgcc.a" (it's possible to use "awk" to pick out a selected function but if you just list the entire thing to a file then search that you will find something like:

_copy_data.o:     file format elf32-avr


Disassembly of section .init4:

00000000 <__do_copy_data>:
   0:	10 e0       	ldi	r17, 0x00	; 0
   2:	a0 e0       	ldi	r26, 0x00	; 0
   4:	b0 e0       	ldi	r27, 0x00	; 0
   6:	e0 e0       	ldi	r30, 0x00	; 0
   8:	f0 e0       	ldi	r31, 0x00	; 0
   a:	00 c0       	rjmp	.+0      	; 0xc <__do_copy_data+0xc>
   c:	05 90       	lpm	r0, Z+
   e:	0d 92       	st	X+, r0
  10:	a0 30       	cpi	r26, 0x00	; 0
  12:	b1 07       	cpc	r27, r17
  14:	01 f4       	brne	.+0      	; 0x16 <__do_copy_data+0x16>

_clear_bss.o:     file format elf32-avr


Disassembly of section .init4:

00000000 <__do_clear_bss>:
   0:	20 e0       	ldi	r18, 0x00	; 0
   2:	a0 e0       	ldi	r26, 0x00	; 0
   4:	b0 e0       	ldi	r27, 0x00	; 0
   6:	00 c0       	rjmp	.+0      	; 0x8 <.do_clear_bss_loop>

00000008 <.do_clear_bss_loop>:
   8:	1d 92       	st	X+, r1

0000000a <.do_clear_bss_start>:
   a:	a0 30       	cpi	r26, 0x00	; 0
   c:	b2 07       	cpc	r27, r18
   e:	01 f4       	brne	.+0      	; 0x10 <.do_clear_bss_start+0x6>

So that is all that is in libgcc.a - it does not include links to source code files for this (what would be the point? The references would be to files on the PC of the person who built the compiler - files you don't have). The above is exactly the code you may have seen as part of your program:

 

 

 

that RJMP, LPM, ST, etc sequence is exactly:

   a:	00 c0       	rjmp	.+0      	; 0xc <__do_copy_data+0xc>
   c:	05 90       	lpm	r0, Z+
   e:	0d 92       	st	X+, r0
  10:	a0 30       	cpi	r26, 0x00	; 0
  12:	b1 07       	cpc	r27, r17
  14:	01 f4       	brne	.+0      	; 0x16 <__do_copy_data+0x16>
  ...

And going back to my first link in this post the source is at line 2404:

#elif !defined(__AVR_HAVE_ELPMX__) && !defined(__AVR_HAVE_ELPM__)
	ldi	r17, hi8(__data_end)
	ldi	r26, lo8(__data_start)
	ldi	r27, hi8(__data_start)
	ldi	r30, lo8(__data_load_start)
	ldi	r31, hi8(__data_load_start)
	rjmp	.L__do_copy_data_start
.L__do_copy_data_loop:
#if defined (__AVR_HAVE_LPMX__)
	lpm	r0, Z+
#else
	lpm
	adiw	r30, 1
#endif
	st	X+, r0
.L__do_copy_data_start:
	cpi	r26, lo8(__data_end)
	cpc	r27, r17
	brne	.L__do_copy_data_loop
#endif /* !defined(__AVR_HAVE_ELPMX__) && !defined(__AVR_HAVE_ELPM__) */

But, as I say, this source does not make it into the built library code because the way -g debugging works is that in ELF files that do have links to source the ELF file itself does not contain lines from the .S / .sc / .cpp source files themselves. It just says things like "these 10 opcodes are as a result of lines 13 to 17 in file d:\compiler\builder\source\foo.c" and because you don't have d:\compiler\builder on your own machine there'd be no point in libgcc.a being built with links to source files you don't have access to.

 

Of course you can do exactly what I did and go out onto the internet and find the source code that was used to build the compiler you are using and then you can get to see the actual source in things like libc.a, libm.a, libgcc.a and so on. I found my cpoy of the libgcc sources here:

 

https://github.com/gcc-mirror/gc...

 

HOWEVER while it looks like the one there that I have listed some bits from looks a lot like the code you have found built into your AVR program there is a caveat: It's the WRONG VERSION. The files in that github are @HEAD - that is source with the most recent commit 6 days ago. This almost certainly is NOT the code as it was when 5.4.0 was released several yeas ago. Sure __do_dopy_data may not have changed in years (in fact I found a git blame that showed it could be 16 or even 20 years old!) but you really need a copy of the tree at the 5.4.0 release tag to see a true copy of how libgcc source was for the tree that built the copy of libgcc.a that is on your hard drive.

 

All of the foregoing is equally true of libc.a. The source for that is found at:

 

http://svn.savannah.gnu.org/view...

 

That has the same version issue and it too is built about 18 times to create all the different avr25, avr3, avr5, etc etc architecture variants you find in:

 

Here you see libc.a and libm.a but also the various printf() suppport libs and in addition to all this are the 300 odd copies of crtXXXX.o - one for every variant of AVR that exists

 

(actually they are not all in this directory tree - these days some are delivered by the "packs" directories too).

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


You are building your project with Debug info, aren't you?

 

 

The 'Release' Configuration has no debug info:

 

The "Debug Info" is what allows the Debugger to tie the raw addresses that it sees to the lines in your Source code (also things like variable names, function names, etc)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Andy? The code he is showing is lib/gcrt code - it wouldn't matter what he does the libs and .o files are avr-strip'd !!

 

When I look at David's version of his project and the code from the files HE provided:

 

 

There is no problem - it is intermingled source and code. It's only the LIB/CRT sections (as expected!) that show "no source file" for all the reasons I have already given.

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


 

clawson wrote:
The toolchain that comes with Studio 7 is effectively in 4 parts.

enumerating:

  1. There is a compiler/preprocessor from the GNU Compiler Collection,
  2. (a) there is an AVR assembler,

    (b) linker

    (c) and other utilities from GNU "Binutils" (binary utilities).
  3. There is a prebuilt copy of AVR-Libc that has stuff (built specifically for AVR) like memcpy, printf, sin, cos, tan and so on.
  4. Then there are the prebuilt "GCC libraries".

 

Perhaps this diagram will help to understand how these all fit together in the build process:

 

 

See this thread for more details & diagrams: https://www.avrfreaks.net/forum/avr-gcc-compiling-linking-and-assembly

 

EDIT

 

in the diagram:

other programmers and debuggers are available 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jan 11, 2022 - 11:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The code he is showing is lib/gcrt code - it wouldn't matter what he does the libs and .o files are avr-strip'd

Yes - but it might explain the general issue about the "ghost" breakpoints in the source window:

 

 

 

EDIT

 

Yes, David's version does have the 'Debug' configuration selected - but we're not sure that's exactly what the OP had/has.

 

And what the OP has is clearly different somewhere ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jan 11, 2022 - 11:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I think OP needs to post a ZIP of the code he's actually using. With the "David version" the breakpoints on those two lines work just fine in simulation. So something has changed between the original version and the one David created.

 

(or OP could just switch to using David's)

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

clawson wrote:
I think OP needs to post a ZIP of the code he's actually using.

Indeed.

 

With the "David version" the breakpoints on those two lines work just fine in simulation.

Agreed.

 

So something has changed between the original version and the one David created.

Or something else is messed up locally on OP's machine; eg, corrupt .atsuo, object out-of-date with source, other ... ?

 

(or OP could just switch to using David's)

+1

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 there is an AVR assembler

 

I don't think AVR ASM (or its cousin AVR ASM2) has a linker, or does it nowadays?  It has been quite a while since I looked for it, but back in Studio4 days was told it didn't support that.  And that was the last time I was interested in doing linked ASM project anyhow!

I just hit build & let everything go through its paces each time.  Now we have so many more options, it really seems those were ancient times (just 10 years ago).

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: 1

avrcandies wrote:
I don't think AVR ASM (or its cousin AVR ASM2) has a linker, or does it nowadays?
Your talking about the wrong assembler. Atmel's standalone avrasm2 is indeed a very simple two pass, non-linking assembler. The assembler that is part of the C/C++ compiler toolchain is avr-as, the GNU Binutils assembler and it is most definitely a linking assembler.

 

Given that the C and C++ compilers are nothing really more than C/C++ to Asm converters then all the C and C++ (and even .S Asm source) you write win GCC is ultimately compiled by avr-as and then it is the Binutils linker (avr-ld) that is then invoked to link together all the .o files that avr-as has created. It's why GCC makes it so easy to mix together languages. Some part of a project can be in C, some in C++,and some in .S (Asm) sources. You can have any combination of those you like so it's quite feasible to create a completely Asm only project using nothing but avr-as (being fed from .S and .s files) and write linkable programs and even static libraries in Asm.

 

Studio 4 only came with Avrasm2 (and its predecessor) from Atmel. It was not supplied with a copy of GCC so it did not (immediately) have access to avr-as. However as soon as you added "WinAVR" that included avr-as (as well as avr-gcc, cl1, avr-g++, avr-objcopy, avr-objdump, avr-ld, etc etc).

 

Back in AS4 days I think people only added WinAVR because they wanted a "C compiler" (probably not even a C++ compiler) and may not even have been aware that part of what they were adding included a very powerful assembler (even though the whole of C and C++ were totally reliant on it!). Few would have realised that they could start a "GCC project" but them make it completely Asm only !

 

Of course since AS5 Atmel then included GCC as well as Avrasm2 as build tools so anyone using Studio 5, 6 or 7 now has a choice without needing to download and install anything else.

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

In an ideal world you would collaborate on GitHub.   Everyone could see the current code.  Everyone would see the state of the AS7.0 project.

 

Personally,  I think it would be wise for the OP to gain experience with C, AS7.0, Simulator, debugging, ... on a very simple project.

Paste the current source code to his message.   Readers could keep track.

 

Yes,  I think that learning on the actual "useful project" is good for enthusiasm.   e.g. we could just assume that we all have the "anto1_ol_328_kbv.zip" that I posted earlier.

But this is after the OP has gained experience with blinking LEDs, writing USART, timer, ...

 

If the "useful project" is actually a port of a known public "working project",  it would be wise to link to the original code.

Then we could show the steps involved.   And most importantly,  explain how and why.

 

David.

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

david.prentice wrote:
Personally,  I think it would be wise for the OP to gain experience with C, AS7.0, Simulator, debugging, ... on a very simple project.

Absolutely.  It does seem that there is some basic understanding missing on the whole C build / programming /debugging process.

 

Paste the current source code to his message

You mean the source code of the  very simple project ?

 

With just the main.c of the current project being nearly 3300 lines, that's far too big to go in a post!

 

 after the OP has gained experience with blinking LEDs, writing USART, timer, ...

Absolutely - see: https://www.avrfreaks.net/commen...

 

Again, Microchip's tutorial - https://onlinedocs.microchip.com... - comes complete with simple source code to work with ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
In an ideal world you would collaborate on GitHub.
Totally agree with that - half the time you would see the "problem" simply browsing around in the web interface without even needing to download anything.

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

No,  I mean paste the current source code of the  very simple project.   e.g. 20-40 lines.

 

The "useful project" would be much less than 3300 lines if my earlier advice was taken.

If the OP showed an interest,  I could do the "tidy up" for him.   This makes projects more manageable.

 

From memory,  the project ZIP is about 10kB.   i.e. perfectly attachable.   Note that you "make clean" before you ZIP.

So it is no harm in attaching a whole 10k ZIP to a message.   Much less storage than some of the photos that get sent.

 

And it means that we know the exact state of the OP's project at the time of posting.

Of course GitHub could do all the housekeeping but the OP would have to learn GitHub at the same time as everything else.

 

David.

 

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

david.prentice wrote:
I mean paste the current source code of the  very simple project.   e.g. 20-40 lines.

Yes - that's what I said.

 

david.prentice wrote:
From memory,  the project ZIP is about 10kB

Windoze says it's 32K - but that's still perfectly feasible to attach.

 

david.prentice wrote:
Much less storage than some of the photos that get sent

indeed.

 

The "useful project" would be much less than 3300 lines if my earlier advice was taken.

The uncompressed main.c  is 155K !  surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Again, Microchip's tutorial - https://onlinedocs.microchip.com... - comes complete with simple source code to work with ...

Attached is that code in a Studio Project which builds and runs in the Simulator.

 

The Zip is 28K; main.c is just 68 lines.

 

I commented-out the "region" #pragmas - as they gave warnings:

AvrSimGettingStarted\main.c(29,0): warning: ignoring #pragma region LED_functions [-Wunknown-pragmas]
		 #pragma region LED_functions
		 ^
AvrSimGettingStarted\main.c(53,0): warning: ignoring #pragma endregion LED_functions [-Wunknown-pragmas]
		 #pragma endregion LED_functions
		 ^

 

Attachment(s): 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

       in tutorial said there, that u can set and remove breakpoint while simulator has running?

 

Not exactly that, do Pause first, and then set breakpoint.

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

grohote wrote:
do Pause first, and then set breakpoint.

See #59 - the Simulator does allow you to set & clear breakpoints while it's running

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!  That clarified a lot...Whenever I made an ASM project (much rarer nowadays) , I just defaulted to good old ASM2. 

 Few would have realised that they could start a "GCC project" but them make it completely Asm only !   If I do another pure ASM project I'll try the GCC assembler.

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

True, no Simulator can do it, only Real debugging.

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

It's the other way around - real hardware can't do it, but the simulator can.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

You are building your project with Debug info, aren't you?

 

The 'Release' Configuration has no debug info:

 

The "Debug Info" is what allows the Debugger to tie the raw addresses that it sees to the lines in your Source code (also things like variable names, function names, etc)

thanx so much. it's the most useful advice i had got. i had followed by ur directions, and has  got these results :

even I had didn't read  about this trick  in simulator manual.pdf or in tutorials .

atmega328p

Last Edited: Wed. Jan 12, 2022 - 07:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I think that would be easier to follow as a sequence of static images rather than an animation?

 

So, to start with, you had this:

This is strange,  as the 'Debug' Configuration - as its name suggests - certainly should have Debug enabled!

 

EDIT - See this recent thread: https://www.avrfreaks.net/commen...

and note that this is pretty standard practice - not specific to Microchip Studio or AVR or even embedded.

 

I had didn't read  about this trick  in simulator manual.pdf or in tutorials

It's not just for the Simulator - this would apply to any form of debugging.

 

Did you follow all of the tutorials in order, or just jump straight into the Simulator one?

 

Perhaps setting up a Project for Debug was covered in an earlier Tutorial?

 

EDIT 2

 

No, it doesn't seem that the need for Debug Info is mentioned in either the Simulator or the Project Creation tutorials.

 

Perhaps you could raise a Support issue with Microchip to point that out?

 

However, again, it should have been there - so perhaps look into how you created this project, or where you obtained it ...

 

As David says, this is where it helps to use a simple project to learn basics on ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 12, 2022 - 10:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


You say "by default" the debug level was set to "none" in the "Debug" build settings but this is NOT the default? Just start a brand new project and you will find that by default it is...

 

 

So you must have edited this at some stage or did the project get into Studio 7 by some other means than simply File-New project... ? (like an upgrade/import).

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


As clawson pointed out in #70, this 'Debug Level' setting only applies to building from source - so you still won't get to see any source  info for the pre-built libraries.

 

So if you happen to hit the pause button  while the processor is executing something within a library, you will still get the disassembly view - no source.

 

in #55, awneil wrote:
If you use 'Start Debugging & Break', then it starts the simulation and immediately halts at the first line in main() -

In your original project, with no debug info, the debugger wouldn't have known where "the first line in main()" was - which probably explains why it just halted at the start of the C startup stuff ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Perhaps setting up a Project for Debug was covered in an earlier Tutorial?

not only here but in few sources in internets , i didNt find this info.

 anycase it's useful info, maybe for somebody else.

 

as to me, i had run debugger in AS 6/7 before, and all worked  by default. So, i had never need this point.

But after i had installed the new PC, i had debugging feature lost and started to think 

about the real hardware debugger can help me.

and now i think, that i was too hurry - if i can continue to simulator  use now.

atmega328p

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

anto1 wrote:
i had run debugger in AS 6/7 before, and all worked  by default

Why the light grey - just to make it harder to read?

 

anto1 wrote:
after i had installed the new PC, i had debugging feature lost and started to think

It wouldn't have just got lost - someone must have changed it somehow.

 

This illustrates why you should have a so-called Revision Control System - eg, Git or SVN

 

Then, when stuff "stops working" you can go back to previous versions to see what changed ...

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You say "by default" the debug level was set to "none" in the "Debug" build settings but this is NOT the default? Just start a brand new project and you will find that by default it is...

of coarse , not. i just have meant , that before awneil advice , the my A.S.7 state was in a such position . I don't know , how it become  here ,

just i can supposed, that's was happened  because of improperly  installation.

because  while the online installation  there was error messages, and installation didn't  completed few times  at all.

but one time it has completed, so i had keep it out in spite of the some error  messages  has remained  on.

 

as to return to not default setting, it can be just of the appropriate set of flags has not properly value,

because of memory defect?

for example 0b01010110 has accidentally becomes  0b01010010, while installing?

atmega328p

Last Edited: Wed. Jan 12, 2022 - 10:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

anto1 wrote:
happened  because of improperly  installation

I can't see how that could affect project settings like that.

 

Again, get a decent Source/Revision Control system!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A thread on Software Version/Change/Revision Control tools: https://www.avrfreaks.net/forum/program-help-me-roll-back-older-versions-my-code

 

Note that the specific reason for starting that thread was exactly, "my code stopped working, and I want to go back to when it las worked" ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Just to note that the place where the -g2 setting is held is in the .cproj file for the project:

<avrgcc.compiler.optimization.DebugLevel>Default (-g2)</avrgcc.compiler.optimization.DebugLevel>

so if the setting changed it's because that file changed (something usually only accomplished by changing things via the GUI and then saving the project).

 

As Andy says, if you used revision control it would be a simple matter ("git blame") to know exactly when and why that line in that file changed.

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

awneil wrote:
"my code stopped working, and I want to go back to when it las worked" ...

thanx. but don't  worry  about this, i had edit the new copy  every time, of coarse .

so i had never found that error  without ur advice  for project settings  tuning, because  of it's

not my code and i never guessed, where i need to go to .

 

clawson wrote:
Just to note that the place where the -g2 setting is held is in the .cproj file for the project:

i 'm not have  so deep  knowledges before and didn't  checked  .cproj file.

even  as i keep  all previous versions (this is 14th edition )

but next time i will keep it in mind. thanx 4 ur directions

 

upd: by ur directions i can find that in old versions (8th) was this line for debug level

        <avrgcc.compiler.optimization.DebugLevel>Maximum (-g3)</avrgcc.compiler.optimization.DebugLevel>

but this version was definitely wrote on another (old) PC

 

atmega328p

Last Edited: Wed. Jan 12, 2022 - 01:50 PM

Pages