From SEGGER Wiki
Revision as of 17:23, 19 November 2018 by Nino (talk | contribs) (How to)

Jump to: navigation, search

Automated test example

Ozone features an advanced Scripting interface which can be used for automated tests as well. A simple example of such a setup will be shown in the following article. This can then be used as baseline to e.g. export Code Profile or Instruction Trace reports.

Example Setup Requirements

For the automated test example that will be shown in this article the following minimum requirements must be met:

  • J-Link software V6.30h or later
  • Ozone V2.56f or later
  • Any J-Link/J-Trace model (Base or higher) that can be used with Ozone
  • SEGGER Cortex-M Trace Reference Board with a STM32F407 target device

Example project

The following sample project is designed to be used with J-Link/J-Trace and Ozone to demonstrate automation with Ozone. The project has been tested with the minimum requirements mentioned above and a Cortex-M Trace Reference Board. The sample project comes with a pre-configured project file for Ozone that runs out-of-the box. In order to rebuild the sample project, SEGGER Embedded Studio can be used. The example project can be downloaded here:


The following steps will be executed in the example:

  1. Load test application
  2. Set a breakpoint
  3. Run to the breakpoint
  4. Execute a function that has been set to run when breakpoint is hit
  5. Close Ozone

Note: This is only an example test automation and it can be adjusted to individual needs using the extensive scripting interface of Ozone. More information can be found in the Ozone user manual.

Dual core debugging example based on NXP LPC4350

This article describes how to setup dual core debugging with Ozone the J-Link debugger.

Required soft- and hardware

The sample project has been tested with the following components:

  • J-Link
  • Arrow LPC-4350-DB1 Rev.B evaluation board
  • J-Link software version V6.32g or later
  • SEGGER Embedded Studio V3.40
  • Ozone V2.56s

Running the sample project

The Cortex-M4 simply sends a defined command to the Cortex-M0 using shared memory and waits for the response before it resumes execution. The Cortex-M0 waits for command reception from the Cortex-M4 and simply sends back a "received-response" using shared memory.

To run the sample project at first open the project Ozone_Multicore_LPC4350_CM4.jdebug with Ozone and start a debug session. Then open a second instance of Ozone with the project Ozone_Multicore_LPC4350_CM0.jdebug and start the debug session. Now you can independently run, halt and step both cores. Please note that starting the Cortex-M4 will issue a system reset and affect both cores, so the Cortex-M4 always has to be started before the Cortex-M0.

Included files

Filename Content
Readme.txt Readme file with instructions for debugging
LPC4350_CortexM0_SES\LPC4350_CortexM0_SES.emProject Cortex M0 core project file
LPC4350_CortexM0_SES\Src\* Cortex M0 core project source files
LPC4350_CortexM4_SES\LPC4350_CortexM4_SES.emProject Cortex M4 core project file
LPC4350_CortexM4_SES\Src\* Cortex M4 core project source files
Ozone_Multicore_LPC4350_CM0.jdebug Cortex M0 Ozone project
Ozone_Multicore_LPC4350_CM4.jdebug Cortex M4 Ozone project

NXP LPC4350 Embedded Studio Projects


Start debug session with bootloader

Whenever a new project is created with Ozone, Ozone will assume that the .elf file you opened also points to the starting point of your application. This is usually the case. However should you have e.g. a bootloader that needs to be executed first the Ozone project must be edited accordingly.

How to

Each Ozone project is saved as a .jebug file. The Ozone project itself is written in a C-like scripting language and can be edited if needed. Per default functions AfterTargetDownload() and AfterTargetReset() will be populated with the following code lines for Cortex-M:

unsigned int SP;                                                
unsigned int PC;                                                
unsigned int VectorTableAddr;                                   
VectorTableAddr = Elf.GetBaseAddr();                            
if (VectorTableAddr == 0xFFFFFFFF) {                            
  Util.Log("Project file error: failed to get program base"); 
} else {                                                        
  SP = Target.ReadU32(VectorTableAddr);                         
  Target.SetReg("SP", SP);                                    
  PC = Target.ReadU32(VectorTableAddr + 4);                     
  Target.SetReg("PC", PC);                                    

And the following for ARM or Cortex-A/R:

unsigned int PC; 
PC = Elf.GetBaseAddr();                                         
if (PC != 0xFFFFFFFF) {                                         
  Target.SetReg("PC", PC);                                    
} else {                                                        
  Util.Log("Project file error: failed to get program base"); 

Either way the PC will be set to a wrong position if first a bootloader needs to be executed. To counter this the .jdebug default values need to be edited as follows:

unsigned int SP;                            
unsigned int PC;                            
SP = Target.ReadU32(<SPLocation>);     
Target.SetReg("SP", SP);                
PC = Target.ReadU32(<PCLocation>);
Target.SetReg("PC", PC);   

Where <PCLocation> and <SPLocation> are the addresses (e.g. 0x00000000) where PC and SP are stored. For Cortex-M target this is usually at BootloaderBaseAddr + 0x0 for SP and BootloaderBaseAddr + 0x4 for PC.

Example project

Example projects can be found for the following devices: