simulator issue in Studio 7

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

Hello,

 

I am using Atmel studio 7.0.634

I have a gcc project for Attiny461a. The source is bulding without errors.

I want to use the simulator. So after choosing the simulator I launch the "start debug and break".

 

Then, sometimes the program is running without stopping, sometimes it starts but with opening a window with disassembly code and the yellow arrow for debug inside !!

In this disassembly code there is the mention "no source file"! 

If I close the dissambler window, then nothing is running in the source code.

 

I don't understand at all.

Please help me, the simulator seems totally bugged with this attiny or do i need to change some parameters??

 

thanks in advance.
Best regards.
FGRAS78

 

screen capture

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

Looking at your screenshot, you have built for Release instead of Debug.
Since you are using the Simulator, there is nothing much to go wrong.

David.

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

Thanks David,

 

yes it works now!

For my information, what is the difference to build for release or debug?

I have not seen in the Help that for starting a debugging session we must choseaccordingly the build option first.

 

I still have a minor issue : 

If i stop debugging, then I am not able to start it again. 

Then I must exit Studio 7 and launch it again and load the project. It seems to be a bug?

But it's not so important as I can now debug with the simulator at least.

 

Thanks again and Best regards.
Fabrice.

 

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

AS7 will always start off with you in Debug mode.  Look at the box just below the Windows Tab.

With a C program: The Symbol DEBUG is defined for Debug Configuration.  NDEBUG is defined for Release.

With a C++ program,  my AS7 always has the Symbol DEBUG.   (this seems wrong to me)

 

Debug Information is generated for a Debug build and NOT for the Release build.

Of course you can change all these "defaults" to suit your project.

I try to set these things in "All Configurations".   Otherwise you get a shock if the Release is different to the Debug build.

 

You can often "Restart" a CPU at 0x0000 from the Debug menu.

It is probably safer to Stop the Debug session and Start another Debug session.

 

It is best to have a play with the Simulator to get a feel for how everything works.

 

David.

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

fgras78 wrote:
I have not seen in the Help that for starting a debugging session we must choseaccordingly the build option first.

That couldbe because the build configurations (as the proper name for them is) is fully customizable. I.e. it is possible (but perhaps stupid) to set the option to generate debug info in the Release configuration.

 

You can see the differences yourself by looking in the project properties, Toolchain, AVR/GNU C Compiler.

 

For Debug the options to the compiler is

 

-x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\include"  
-O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega16 
-B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega16" 
-c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" 

The key things here are

-DDEBUG

which has the same effect as doing

#define DEBUG

in every source file (so you could have conditional compilation depending on build configurations using #ifdef/#endif in your sources), and

-g2 

which tells the compiler to generate debug information (at a certain level). Also interesting is

-O1 

which sets optimization at a relatively low level (this makes the actual "flow" of the generated machine code more similar to the C source "flow" making debugging somewhat less confusing).

 

For Release the options are

-x c -funsigned-char -funsigned-bitfields -DNDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\include"  
-Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=atmega16 
-B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega16" 
-c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" 

so it's "NDEBUG" instead of "DEBUG" in the define, there is no -g option at all so no debug info will be generated, and the optimization is -os which we might call "highest level" (debatable...).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Debug Information is generated for a Debug build and NOT for the Release build.

Is this true of ASM projects? Never noticed it, the .hex file seems the same.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

HEX files will always be the same. They do not contain Debug information.

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

Everything above is re the GNU toolchain, an dspecifically the AVR-GCC compiler and GNU ld (the linker).

 

I suppose you're asking about the Atmel assembler (rather than GAS, the GNU assembler).  The Atmel assembler is a "one-translation-unit", non-linking one. So the only set of options are the ones for the assembler as such, and for a boiler-plate project they are

-fI -o "$(OutputFileName).hex"  -m "$(OutputFileName).map"  -l "$(OutputFileName).lss"  -S "$(OutputFileName).tmp"
-W+ie -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\avrasm\inc"
-I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\avrasm\inc"  -im328PBdef.inc -d "$(OutputDir)/$(OutputFileName).obj"  "$(EntryFile)" 

You're the resident assembler programmer here, so you tell us what all that means ;-)  Apart from the occasional intellectual exercise, and for low-level debugging, I'm not using assembler on the AVR any more. (If a few akwardnesses could be solved we could all move on to C++ right away... ;-)

 

Re "the hex files seems the same"  you're correct. And this holds true for the GNU tool chain also. There is no debug info pushed into the flash of the AVR in any case. The debug info resides on the debug host only. It is there the mapping from machine addresses to the source symbol names etc is taking place. For the GNU tool chain, the debug info, used by e.g. Studio during a debug session, is in the ELF file.

 

What does affect the HEX is the optimization level chosen, but that has nothing per se to do with debugging info generated or not.

 

Oh OK, lets have a stab at the Atmel Assembler options. Studio help to the rescue!

-fI                                     ; Output format Intel Hex
-o "$(OutputFileName).hex"              ; Output filename
-m "$(OutputFileName).map"              ; Generate map file
-l "$(OutputFileName).lss"              ; Generate listing file
-S "$(OutputFileName).tmp"              ; Produce include/label info file for Atmel Studio
-W+ie                                   ; Generate error for unsupported instruction
-I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\avrasm\inc"  ; Include path
-I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\avrasm\inc"  ; ...twice just to make sure
-im328PBdef.inc                         ; Include file
-d "$(OutputDir)/$(OutputFileName).obj" ; Generate debug info in this file
"$(EntryFile)"                          ; The file to assemble (a Studio "meta-variable" expanding to the name of the assembler source)

Observations:

 

  • I have no clue what "Produce include/label info file for Atmel Studio" means. OK, perhaps a little clue..
  • Debug info is generated into a .obj file
  • I don't know if Studio pulls symbolic debug info from the .obj or from the "label file" but since the latter file type is .tmp this kind-of suggests that it is an intermediate file I'm betting on the .obj file for debug info.
  • Yes, Studio actually sets that include path twice (-:
  • There is no difference in the assembler options between the Debug and Release build configurations

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Nov 29, 2015 - 07:56 PM