Why is the application not running stand-alone?

Introduction

There can be numerous reason for an application not running. This Technical Note will focus on the following situation.

The situation is:

• The application only works when using the C-SPY debugger and with a connected debugger probe.
• The application does not work in stand-alone mode (that is, after disconnecting and power cycling the board).

Background

There are major differences between running an application using the C-SPY debugger, compared to running stand alone.

When debugging the application with the C-SPY debugger, a number of SFRs are set by:

• the flashloader source code.
• the mac file used by the flashloader.
• the mac file used by the application.

When the application runs standalone these SFRs need to be set by the application in the startup/initialization code.

There are also other possible explanations to why an application does not work in standalone mode. See solutions below.

Suggestions

1. Check if a Flash loader is in use (Options > Debugger > Download). If a flash loader is configured, it probably means that a flash loader macro file is used. Check the .board and .flash files for references to macro files .mac. Open the macro file and see what it does. Consider if this needs to be done in the application startup code? Disabling the flash loader can be a way to find out.
2. Check if the application is using a Setup macro file (Options > Debugger > Setup). Open the macro file and see what it does. Is there a need to do the same in the application startup code? Disabling the setup macro file can be a way to find out.
3. Using printf() in the application code can cause the application to hang forever when no debugger is connected, depending on the project settings. A way of checking the use of printf(), is to set Options > General Options > Library Configuration > Library low-level interface set to 'None'.
   For an ARM Cortex it is possible to keep the calls to printf(). If so, make sure that Options > General Options > Library Configuration > stdout/stderr is set to 'Via SWO'.
4. A non-disabled Options > General Options > Library Configuration > stdout/stderr > 'Via Semihosting' may cause the application to halt at a BKPT-instruction. These BKPT are used by the semihosting system when sending the SWI interrupt for the semihosting. (Disable at Options > General Options > Library Configuration > Library low-level interface set to 'None').
   
   
5. Certain hardware on the target device may need time to initialize (PLLs, etc). If the application does not wait for these kinds of intilizations, problems may occur. When running in a debugger, the application often halts at main(). This gives time to initialize, but when running the device stand alone, there will be no extra delays. To find out, add a long delay loop as the first thing in main(). If this helps, this points to the need to add code to wait for device initialization.

 All product names are trademarks or registered trademarks of their respective owners.