Search FAQs on the left to see if your question has been answered. Click on the dropdown to view all of the documents associated with the product. If you can't find your question, click on Ask a Question

FAQ: "Why does my application run in DEBUG mode but not in RELEASE mode?"

Some application examples might work in debug mode but not in release mode. This means that when you reset the microcontroller and try to run without a debugger connected, the application code might not execute as expected. This might be due to certain debug specific options being used in the application project. This FAQ describes how to overcome the problem. 


Applications such as some example applications accompanying ADuCM302x and ADuCM4050 software packs that use the 'DEBUG_MESSAGE' or 'DEBUG_RESULT' macros in their code, can hang in release mode because these macros map to the sprintf function that is supported via semi-hosting by default. Semi-hosting means, that the macros get executed only when a debugger is connected.


A workaround for this issue exists, and comprises of modifying the common.h file that can be found in the Include directory of the device driver (DFP) installation (typical path in case of IAR as an example: 'C:\Users\<user-name>\AppData\Local\IAR Embedded Workbench\PackRepo\AnalogDevices\ADuCM4x50_DFP\3.1.1\Include\common.h'). The common.h file can also be modified within IAR workbench where it would be available under the '<project-name>\CMSIS-Pack\Device Examples Support' directory within the project hierarchy in the IAR source browser. 


In the common.h file, modify the definitions of the DEBUG_MESSAGE and DEBUG_RESULT macros such that they don't map to sprintf function calls in case the NDEBUG macro is set. A modified common.h file is attached for reference. 



The NDEBUG macro is set automatically when the 'Release' configuration is selected in the project workspace (see example IAR snapshot below where the 'Release Mode' is being selected). As a result of this workaround - the application example should now be able to run through completely, in release mode as well. 



Note: With BSP revision 3.1.x and earlier revisions, there is an additional issue with the button_press example. In button_press.c, the application waits for a default number of core clock cycles, before exiting. As a result, even with the workaround above - while the application will run through completely in release mode, it would most likely exit too quickly for a user to experiment with pressing the buttons. To resolve this, modify the button_press.c file to comment out the default while() loop, and add a while(1) loop instead, that ensures that the user can freely experiment with the example in release mode for as long as required.