Why is the application not running stand-alone?

Introduction

There can be numerous reason for an application not running. This Technical Note relates to these observations:

• 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).

The most common root causes for problems when running stand-alone are:

• Trying to run an application without starting up execution in the bootloader. This cause is covered in technical note 240109.
• The C-SPY debugger isn't available to set up needed SFRs (Special Function Registers). This cause is covered in this technote.

Discussion

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.

The following are advice related to p.1, top above.

Identifying files by traversing the configuration files

For each device possible to select in the General Options > Target > Device > drop-down-meu, there is one .i79, with the same name as shown on the menu line.

• The contents of the .i79 file (it is in plain text format) is the starting-point for finding files involved in the flash-loading process.
• Open the correct -i79 file in the <installation_path>\arm\config\devices\<chip_vendor>\ directory.
• Copy the information about:
  • DeviceMacros (.dmac files)
  • FLASH LOADER (.board file)

Note the references to $TOOLKIT_DIR$\config\ So the .dmac file(s) and .board file are in other sub-directories to the \arm\config\ directory.

Examining a .dmac file

• Open the .dmac file in a text editor.
• Identify which macro-functions (in the .dmac file) that are listed as 'reserved setup macro function names' documented in the Debugging Guide.
  • Such macros typically set up SRFs (special function registers).
  • Such 'setting an SFR' should be included in the stand-alone application.
  • For example: A macro function to check for, is the 'execUserFlashInit' macro function as it is: '...Called once before the flash loader is downloaded to RAM...'

So, the aim is to identify all SFRs that can be set in the flash loading process, and then to consider how to add that to the stand-alone-application.

Examining a .board file

• The board file refers to one (or more) .flash files.
• Copy the paths to the .flash file(s)
• Open it/them.

Examining a .flash file

In the .flash file notice:

• The executable (with extension .out). It is the flashloader itself.
• Check if any .mac (or .dmac) file(s) are referenced.
• The .mac/.dmac file(s) are examined as above.
• (The .out file can't be examined as it is.)

How to examine an .out file

If the device still don't start up stand-alone, that is after implementing the advice 1 to 5, and implementing (in the application) setting of SFRs (from invoked .dmac and .mac files) the flash loader need to be examined.

• Check if the source for the flash loader is available in the \arm\ installation, that is in <installation_path>\arm\src\flashloader\<chip_vendor>\.
  • If the source is there, examine which SFRs are set in that source.
  • If there is no source, you need to contact your chip-vendor, as then they have written the source for the flashloader. You need to ask them which SFRs are set there-in.

Conclusion

This technical note gives advice on where (read: which files) to check which SFRs are set-up by C-SPY and to do the same set-up in the startup/initialization code of the application.

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