How does Debug and Release mode work in Studio7 ?

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


This question is to follow from my previous question related to problems utilizing Studio7 to upload a program onto my Atmega328P.

In this previous question: Sudden Studio 7 weird behavior – no more chip programming possible ?

I managed to settle the problem by doing a fresh restart of my whole OS windows 7 and Studio7 re-install.

Since all my previous program folders were preserve because saved onto another hard drive, I was able to further experiment by recalling some of those previous 'Blinky' codes..

None of them work. They all exhibit the same problem. I just cannot load those Blinky onto my Atmega328P. Yet, if I create a new project from scratch I can upload the Blinky no problem and it run normally. Notice that prior to this major computer rebuild I could not upload anything anymore to my Atmega328P. 

 

So this means, without a doubt, that the problem reside in the actual Blinky folder from before re-install.

Since some of those previous folders contain valuable coding that I don't feel like retyping ( prohibitive size ), hence, I need to find out what's going on with those previous program folders and files.

 

Experimentation included literally erasing both the 'Release' and 'Debug' folders and then do a 'Rebuild Solution'. This rebuild re-created a 'Release' folder but not a 'Debug' folder.

Attempt to program my Atmega328P is not successful for ( I later found out ) there is no 'Debug' folder present in the project folder.

The Output window indicate something like "impossible to read 'Debug/blablabla file ' , of course, the folder is not present ( previously erased )

Then I changed Studio7 into 'Debug' mode and redo a 'Rebuild Solution' and then the 'Debug' folder appeared in the project folder.

Then I swith back to 'Release' mode and proceed to upload the program to the Atmega328P and it worked according to code.

 

So here is the question: Is there a thorough description of the official procedure to upload a code ?

Fact is, I don't really know what are the differences between "Compile" "Build" "ReBuild" "Clean" "Release" "Debug" terms. Of course I have and idea since the words are self explanatory but perhaps not to the extent that one can comprehend exactly what they specifically mean in Studio7. And since I just got out of a major compile/upload problem, I must understand these details thoroughly so I don't fall into that impossible upload again. For instance, why is Studio7 looking for a file in the Debug folder when I am in Release mode ?

Basically I need some kind of tutorial ( if at all available )

 

Thanks

 

 

This topic has a solution.
Last Edited: Thu. Dec 9, 2021 - 01:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This isn't exactly related to your question, but are you using any form of version control (e.g. Git)? You do mention that previous program folders were preserved on another drive, but that isn't really version control. Using version control would allow you to more easily compare versions of your code base to see what change introduced a problem (assuming there is some previous version where the problem wasn't present).

build-avr-gcc: avr-gcc build script

toolchain-avr-gcc: CMake toolchain for cross compiling for the AVR family of microcontrollers

avr-libcpp: C++ standard library partial implementation (C++17 only) for use with avr-gcc/avr-libc

picolibrary: C++ microcontroller driver/utility library targeted for use with resource constrained microcontrollers

picolibrary-microchip-megaavr: picolibrary HIL for megaAVR microcontrollers

picolibrary-microchip-megaavr0: picolibrary HIL for megaAVR 0-series microcontrollers

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

The only version distinction possible is "Before" and "After" the 'Bug' appeared ( thoroughly described in my previous question )

To be precise, all my projects folders are in another partition of the same drive ( but that's not really relevant )

Suffice to say that those projects folders, if stripped of both 'Debug' and 'Release' sub-folders, and rebuilt, will work fine.

If taken 'Raw' they don't work. The programmer act normally and the Atmega328P led will quickly flash ( don't really know why ) and the program will just not run.

I did compare both a newly created Blinky with a previous (prior to catastrophic malfunction ) and apart from project names no apparent differences were detectable. (using file compare).

 

One solution I am starting to tinker about is just to recreate all my projects and just copy/paste the *.cpp text in Studio7 IDE.

While it is substantial work it remains a lot less than retyping by hand.

Still, the main goal here is to get more info on the instructions and to comprehend what are 'Release' 'Debug' and when to use one or the other and also 'Compile' when should one compile or Release or Debug. I'm lost here. 

I was trying to get some information via the Studio7 help feature, frankly, there is so much irrelevant information in these help files, you end up pulling your hairs off your head.

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

OK - Here is a more precise question:

 

          Why is it that when I 'Release' a project and upload the code to my Atmega328P , Studio7 will not update my chip ?

Yet !    Why is it that when I 'Debug'  a project and upload the code to my Atmega328P , Studio7 will       update my chip correctly and the new program will run accordingly ?

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

Maybe you haven't changed the folder where the code is stored? It happens to me at times.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. Dec 9, 2021 - 03:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Looking at your other question, are you using this parameter in the Avrdude command when you try to upload the project in Release mode:  -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

FredCailloux wrote:

Parameters -> Title: FTDI     Command: C:\Cadence\AVRdude\avrdude.exe     Arguments: -C C:\Cadence\AVRdude\avrdude.conf -v -v -p atmega328p -c arduino -P COM4 -b 57600 -D -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i

 

From a your other thread you were asking about Debug and Release.

This is how I setup my "External Tool"

 

Title: Uno_com4

Command: C:\Cadence\AVRdude\avrdude.exe

Arguments: -C C:\Cadence\AVRdude\avrdude.conf -p atmega328p -c arduino -P COM4 -b 57600 -Uflash:w:"$(TargetName).hex":i

Initial Directory: $(TargetDir)

 

This makes the Arguments simpler.  It also means that you can use it for Debug, Release, Your_Own_Custom_Build, ...

 

However you need to choose "All Configurations" when setting Symbols, Paths, etc for common project features.

 

David.

 

p.s.  I will copy this message to your other thread.

 

 

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

david.prentice wrote:
p.s.  I will copy this message to your other thread.
je_ruud wrote:
Looking at your other question
These may be saying "don't split things to another thread if there's any chance you are still asking about the same thing" !

 

David has your answer here (Initial Directory set parametrically to select "Debug" or "Release") but to answer the general question of how Debug and Release differ: the only really significant difference between Debug and Release for AVR is the optimisaztion level which should be -Og for Debug and -Os (though some prefer to set it to -O3) for Release.

 

In PC/Linux land the reason you have Debug/Release is because it affects the generated binary you issue to the user and whether it carries a load of symbolic debug info (also whether it has added diagnostics like stack and heap protection) but in the AVR world there aren't really concepts of stack/heap protection and the symbolic debug stuff is "left behind" in the ELF when the HEX is extracted so there's very little distinction indeed - really the only thing of significance being the optimisation setting.

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

clawson wrote:
in the AVR world ... really the only thing of significance being the optimisation setting.

others spring to mind:

  • DEBUG build might have things like extra diagnostic output to a UART, LEDs, etc;
  • it might disable sleep modes - as these are often problematic for debugging;
  • ASSERTs may be handled differently;
  • Watchdog might be configured differently;
  • etc

 

Of course, the further your DEBUG config differs from RELEASE, the more testing of the RELEASE you'll need to do ...

 

And these configurations aren't limited to just DEBUG and RELEASE; eg, you might add a configuration for running on a dev board (as opposed to your "real" hardware).

 

So there's nothing special or magic about DEBUG and RELEASE - they just happen to be the two provided by default.

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 just dug out an AS7.0 project.

 

Debug:   -DDEBUG -Og and includes debug info Program Memory Usage     :    8534 bytes   26.0 % Full

Release:   -DNDEBUG -Os and omits debug info Program Memory Usage     :    8206 bytes   25.0 % Full

 

Yes,  you should test both executables.   The -Og version will probably be slower.  There might be timing issues.

If you find different runtime behaviour,  you can compile with -DDEBUG and -Os.   Or build both with the same Optimisation.

 

In practice you might put conditional DEBUG code into your development build.   e.g. extra print statements

Almost certainly you will reduce "times", "loops", ... when using the Simulator.

 

David.

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

david.prentice wrote:

Debug:     -DDEBUG  -Og and includes debug info Program Memory Usage :    8534 bytes   26.0 % Full

Release:   -DNDEBUG -Os and omits debug info Program Memory Usage    :    8206 bytes   25.0 % Full

:

:

In practice you might put conditional DEBUG code into your development build

 

for example, code that is built in DEBUG  only:

#if defined DEBUG
    // DEBUG-only stuff
    :
    :
#endif

 

code that is built in non-DEBUG only:

#if defined NDEBUG
    // non-DEBUG stuff
    :
    :
#endif

 

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:
others spring to mind:
Yeah but, those are things you CHOOSE to program (or not) with conditional compilation. I'm talking about what's actually different in the way the toolchain builds the code. (not very much at all).

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

You two nailed it big time. How could I have missed that? Computer rebuild, can you imagine !

 

je_ruud wrote:
Looking at your other question, are you using this parameter in the Avrdude command when you try to upload the project in Release mode:  -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i

 

david.prentice wrote:

Arguments: -C C:\Cadence\AVRdude\avrdude.conf -p atmega328p -c arduino -P COM4 -b 57600 -Uflash:w:"$(TargetName).hex":i

Initial Directory: $(TargetDir)

david.prentice wrote:
However you need to choose "All Configurations" when setting Symbols, Paths, etc for common project features.

 

David can you please elaborate on this. I'm not sure what it involves and where to configure these settings. The Tools/Options doesn't seem to deal with that.

 

Thanks again, you guys are awesome !

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


It's whenever you are making project property changes in something like this:

 

 

Note in particular this bit:

 

 

If you just start making changes (that need to affect both "Debug" and "Release" (and any other configuration you may have created)) then at present the section of the properties you will affect is ONLY  for the "Active" one that happens to be "Debug" right now. The changes won't affect "Release". 

 

Most of the time you may want to have subtle differences between "Debug" and "Release" so in this drop down you would pick just one of them before making edits (or take the fact that the whole build is currently set to "Debug" and let it just edit the "Active" one). But for somethings you want to edit both Debug and Release at the same time. In that case, before you start to edit you select "All Configurations" here:

 

 

If you are used to using Visual Studio for your PC based C/C++ work you may well be familiar with this already (Studio 7 is, after all, just Visual Studio 2015 wearing different clothes).