Posts by rals

Excellent, thank you!

/rals

Hello,

We are having a hard time debugging our code base which is primarily C++ based. Class members in derived classes are shown as "outofscope" in some cases. In the following example, a.var1, a.var2, b.var1 and b.var2 are "outofscope". If A class is not instatiated, b.var1 and b.var2 are visible as expected which is strange.

#ifndef ACLASS_H
#define ACLASS_H




class AParent
{
public:
    int var2;
};




class A : public AParent
{
public:
   int var1;


};


#endif

#include "AClass.h"


class BParent
{
public:
   int var2;
};


class B :public BParent
{
public:
   int var1;
};




//If A class is not instantiated, b.var1 and b.var2 are NOT out of scope
A a;
B b;




int main(int, char *[])
{
   while (1)
   {
      b.var1++;
      b.var2++;
   }
}

The issue is not present if the code is compiled with Segger Embedded Studio

Stm32F439
Ozone 3.38f
-O0
GCC toolchain 12.2 (same issue on 14.2)
https://developer.arm.com/-/media/Files/…9F9E16D17A85311

Related issue:

[ABANDONED] Problem with C++ and

Hi AlexD,

I agree that the functionality doesn't really fit well with Ozone either. I was hoping that the all-knowing Ozone user base might provide some insights to alternative solutions.

For me at least, I grow impatient while waiting for the Ozone flash programming to complete (typically 20 secs on our target). I would rather spend the time in my IDE and let the programming happen in the background after a build is complete.

Hopefully, I will think of something during the summer holiday

Best regards,

Rune

Hello,

Some issues are prone to require (a lot of) trial and error to fix. Such cases typically follows the flow:

Change code -> compile -> program elf file in Ozone

To program the elf file one needs to bring Ozone to the foreground for the dialog with the text "The program has been modified by another application. Do you want to reload it?" to show. In many cases I check "do not show again" to avoid the dialog.

Is there any way to let the reloading (and programming) happen in the background avoiding alt+tab'ing to the Ozone Window? This would speed up the development flow. A tool like Autohotkey might be usable, but not ideal (I would like to avoid having too many dependencies in the toolchain).

Windows 10 / Ozone 3.34 / stm32u585 / J-Trace

Best regards,

Rune

Hello Nino,

Thank you for the supplied example project. Sadly, it doesn't work for me. The breakpoint is hit, but the callback is not executed.

I expect "---BP hit!---" to be written to the console which doesn't happen in 3.22a.

Have you tried clearing the breakpoints (or deleting .jdebug.user file) and reloading the project?

If the breakpoint and scriptCallback is already present in the .jedebug.user, the scriptcallback is executed and "---BP hit!---" is output to the console.

So, to get your example to work I could use the following workaround:

1) delete .jedebug.user / or clear breakpoints
1) open the project in 3.20C
2) close 3.20C
3) open 3.22a
4) the scriptcallback is executed when I expect it to be.

Hope this helps

Have a nice weekend,

Rune

Hello Nino,

Indeed the wiki example works out of the box. The wiki example uses Break.SetOnSrc which works, but after modifying the project with Break.SetCmdOnAddr it no longer works.

The specified address 0x08008260 is within valid flash memory space, but not within the application image memory range as you pointed out (the used location was copied from another project).

Modifying the wiki example to use the memory location instead of the source location (main.cpp:128 -> 0x080005D2) gives the same result - "breakpoint not set".

//
  //  Set BP on source line 128 in TraceDemo.c
  //
  // DISABLED Break.SetOnSrc("TraceDemo.c:128");
  //
  //  Set Function which should be executed once BP is hit
  //
  // DISABLED Break.SetCommand("TraceDemo.c:128","OnBPHit");
  //
  //  Set BP on same address as source line 128 in TraceDemo.c
  //
  Break.Set(0x80005d2);
  //
  //Set Function which should be executed once BP is hit
  //
  Break.SetCmdOnAddr(0x80005d2,"OnBPHit");

Regarding the use case for Break.SetCmdOnAddr we use it for debugging a multi-application scenario.

We start by loading symbol information from two applications and a bootloader and extract their start address (Elf.GetEntryPointPC()) and set the breakpoints callback functions using Break.SetCmdOnAddr()

When the application runs and one of the start addresses are hit we load the appropriate application debug information using File.Load()

Using Break.SetCmdOnAddr() in combination with Elf.GetEntryPointPC() seemed more general than using Break.SetCommand() since line numbers can change and we would like to avoid changing the project file too often. Furthermore, I am not sure that Break.SetCommand() can be used when the symbols are no longer loaded? I.e. is a breakpoint from Application A still viable when Application B is loaded?

Best regards,

Rune

Hello Nino,

Thank you for the feedback!

Same behaviour in V3.22a - "breakpoint not set" is printed in the console on project load. I've attached an elf file and .jdebug file for your convenience (just the same project / elf as I referred to earlier).

Also attached is a screendump from 3.22a - note the question mark in "Extras".

I am able to manually add the callback by modifying the breakpoint (F8 -> Extra Actions -> Script Callback)

Regards,
Rune

Hi,

First of - thank you for a great product!

I'm having issues with one of my projects using the Break.SetCmdOnAddr function. In 3.20c it works fine, but in 3.20d and onwards the callback is not added to the breakpoint.
Break.SetCommand works as expected.

Using the following project file (Modified Ozone_Automation_Demo_ST_STM32F407.zip)

void OnProjectLoad (void) {
  Project.SetDevice ("STM32F407IE");
  Project.SetHostIF ("USB", "");
  Project.SetTargetIF ("SWD");
  Project.SetTIFSpeed ("4 MHz");
  Project.AddSvdFile ("Cortex-M4.svd");
  Project.AddSvdFile ("STM32F407IG.svd");
  Project.AddPathSubstitute("C:/Work/TestProjects/J-Trace_PRO_CortexM_Tutorial/Start", "$(ProjectDir)");


  Project.AddPathSubstitute("c:/work/testprojects/j-trace_pro_cortexm_tutorial/start", "$(ProjectDir)");


  File.Open ("./Output/Debug NoOS NoSystemInit/SEGGER Cortex-M Trace Reference Board.elf");
  Debug.SetResetMode(RM_RESET_AND_RUN);


  Break.Set(0x8008260);
  Break.SetCmdOnAddr(0x8008260,"OnBPHit");
}


void OnBPHit(void) {
  Util.Log("---BP hit!---");
}

3.20d console output:

...
Break.Set (0x08008260);
Break.SetCommand ("0x08008260", "OnBPHit");
Break.SetCommand ("0x08008260", "OnBPHit"): Breakpoint not set: 0x08008260
File.Open: completed in 111 ms

3.20c console output:
...
Break.Set (0x08008260);
Break.SetCommand ("0x08008260", "OnBPHit");
File.Open: completed in 172 ms

Best regards,

Rune

Sorry for the delay - I've been on vacation.

I've attached an elf-file compiled with GCC 5.2 (https://launchpad.net/gcc-arm-embedded/5.0/5-2015-q4-major)

Best regards,

Rune

Hello,

I'm having an issue debugging using an elf file compiled and linked with GNU ARM Embedded toolchain using GCC >= 5 (). The issue is not present in GNU ARM toolchain using GCC 4.9.

I'm not sure if this is the right forum, but at least I can share my findings with you.

Our flash layout reserves 0x8000 bytes at the start of the flash (0x08000000) for a bootloader.

...


    bootloader (NOLOAD) :
    {
       _bootloader_start = .;
       /* Bootloader reservation */
       . = ORIGIN(flash) + _application_offset;
    } >flash
    .vectors :
    {
       . = ALIGN(0x100);
       _applicationBegin = .; 
       KEEP(*(.vectors))            /* Startup code */
    } >flash


...

When debugging the application directly (ie. the bootloader is not executed) we expect the PC to be set to the application Reset_Handler function in the Ozone Event handler AfterTargetDownload()

void AfterTargetDownload (void) {
  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);                                    
  }
}

However, both PC and SP is set to zero.

Ozone console:
Elf.GetBaseAddr();
Target.SetReg ("SP", 0x0);
Target.SetReg ("PC", 0x0);

Here's a dump from readelf()

arm-none-eabi-readelf -h artifacts\app_gcc_5.2.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x803e859
  Start of program headers:          52 (bytes into file)
  Start of section headers:          15229296 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         41
  Section header string table index: 38

I'm no expert on elf files, but it seems that "Flags" is missing the "has entry point" (Flags should have been 0x5000402) which might cause Elf.GetBaseAddr() to return 0. When using GCC 4.9 using the same source/linker script "has entry point" is set.

As a workaround, I hardcoded VectorTableAddr to 0x08008000 in the Ozone project file, but it would be nice to know if I am doing anything wrong or missing an obvious gotcha.

Thank you for the support! We really appreciate it. We will avoid using string merging.

/Rune

The issue is not present when "Merge String Constants is disabled. Furthermore, it seems that "Merge String Constants" must be used with "inline small functions" linker option for the issue to be present.

I've attached a SES project that reproduces the issue. Tested with SES for ARM v4.18.

/Rune

Hello,

I'm currently testing the Segger linker and ran into a problem when "merge string constants" is enabled:

strftime(buffer,len,"%d-%m-%Y %H:%M:%S",datetime);

Gives the linker error:

assertion failure: section '.rodata.str.%m/%d/%y.merge' from - Linker created - is not mapped

Digging a little further (after disabling strftime()):

const char* date_format = "%m/%d/%y";

Also emits the same linker error.

const char* date_format = "%M/%d/%y";

does not.

Hello,

We are just starting out using emFile and have a quick question: We intend to format a 64 GiB eMMC using FS_FormatSD() and need progress information on a GUI. We haven't been able to find any way to do this in the API. Any hints?

Best regards,
Rune

Hi,

Thanks for the reply. I will try contacting Pylink support even though I doubt they have specific knowledge on this issue. I guess we should look at a workaround for this issue.

/Rune

Hello,

We use use Python for test automation. Previously we used our own wrapper for jlink.exe since we don't have the SDK. However, recently, we have discovered the Pylink project which acts as a Python interface to the SDK.

We have an issue which we think is related to the JLINKARM dll. When JLINKARM_Close() is invoked some internal timing related test metrics in our DUT changes. If we skip the invocation of JLINKARM_Close() and just exit the test, the DUT is in no way influenced.

So the question is: what does JLINKARM_Close() do? Is it feasible that the call in any way could interfere with the firmware?

I've attached the jlink log where JLINKARM_Close() is invoked just before EOF.

I hope you can give us some hits as to what could cause this issue.

Best regards,

Rune

Great, I will contact sales regarding the SDK!

/Rals

Hi,

Thanks for the response Niklas and rmilne!

I will look into the SDK - the example shown by rmilne indicates that it will be rather simple to implement. However, an excerpt from the documentation would definitely help me along

I still would vote for semihosting-like RTT features.

/Rals

Hello,

I'm investigating using RTT as output for gcov results. We intend to use this setup to get coverage results of continuous integration tests executed by our build environment.

Using gcov means we need a way to create the .gcda files on the host machine. It is my understanding that this is not currently possible to do directly using RTT.

- Has any plans been made for letting RTT support retargeting of syscalls (open, read, write etc.) to be able to interact with files on the host machine?

- How do we implement the RTT tools on the PC (JLinkRTTLogger.exe etc.) in an automated setup? We need to be able to specify which RTT channel to listen to, debugger interface, MCU type etc. I haven't been able to find any way to specify this.

Hi, I'm trying to do a silent/unattended installation of the JLink Software and documentation pack for Windows (5.10h). It seems that the installer has been created with NSIS installer, so using the /S switch almost does the job (Setup_JLink_V510h.exe /S). However, I haven't been able to find information on how to suppress/automate the SEGGER J-Link DLL updater V5.10h which pops up while doing the silent installation. As a result, the installation hangs until I press the "OK" button.

Any ideas on how to get a completely unattended installation of the install?