Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Using ozone v2.56d on Windows 7 x64. I am building code for the nRF51822 using the Nordic dev board 400092 which has a JLink embedded on it.

I use msys2 and arm-gcc to build my source code because the same build environment works on Windows, OSX and Linux. I'm using CFLAGS of -Og -g to build the firmware, and the same Makefile on Linux and OSX produces .elf binaries which Ozone can work with just fine.

However when I build the source in Windows and load the .elf with Ozone, it cannot find any source files. All of the *functions* show up, but double-clicking on a function only jumps to the disassembly of the function.

The documentation for Ozone (UM8025, Jan 30, 2018) indicates that there are commands to specify the source root path as well as adding directories to the search path. These commands are Project.AddSearchPath() and Project.AddRootPath(). There are no useful examples on how to use these commands, and when I guess at it I don't get an error, but I also don't see Ozone try to look for the source. What is provided is a few paragraphs about locating missing source files, but no resolutions. Section 5.14.6.2, for example suggests that I should see a bunch of file icons with exclamation marks in the source window, but instead I see "No source files" instead.

If I use readelf, I can see that this information is in the .elf file, but ozone is perhaps getting confused because the paths are more unix-like than windows-like because of msys:

(my .elf file and .o files are in the _build/ directory off of the project root where all the source code is.)

One complaint I have about Segger's tools in general (JLinkExe, Ozone, JLinkGDBServer, etc.) is the complete lack of *useful* documentation for command line options or, in the case of Ozone, useful documentation on the Console commands. Why isn't there a --help command line option which documents all command line options for these programs, and how does Segger expect people to use the Ozone console without complete documentation on the commands available in the console?

(PS - the code tag should not be swallowing carriage returns; I should be able to paste output from a terminal window or source code without adding double-returns between every line)

This post has been edited 3 times, last edit by "akohlsmith" (Mar 8th 2018, 3:54pm)

Thank you for your inquiry.
When creating a new Ozone project and opening a corresponding elf file Ozone expects that the output file path or name will not change.
Sometimes projects need to be moved. To keep them portable you can use function: Project.AddPathSubstitute

Quoted

These commands are Project.AddSearchPath() and Project.AddRootPath(). There are no useful examples on how to use these commands, and when I guess at it I don't get an error, but I also don't see Ozone try to look for the source.

The prototype information in the manual of the functions should give you enough information to get going. These functions expect a const char*. So that is what you give them. Simply your path you want to add with quotation marks "C:/Example/Path".

Quoted

One complaint I have about Segger's tools in general (JLinkExe, Ozone, JLinkGDBServer, etc.) is the complete lack of *useful* documentation for command line options or, in the case of Ozone, useful documentation on the Console commands.

We gladly take feedback about our products and documentation but this is the first time we hear that our documentation is disliked in general.

Quoted

Why isn't there a --help command line option which documents all command line options for these programs, and how does Segger expect people to use the Ozone console without complete documentation on the commands available in the console?

Ozone is a GUI debugger. CL is only supported to e limited extend as Ozone already has a powerful scripting interface that makes CL options mostly obsolete.
Should you find an Ozone script function not documented feel free to contact us and we will take care of it.

Quoted

PS - the code tag should not be swallowing carriage returns; I should be able to paste output from a terminal window or source code without adding double-returns between every line

This was not reproducible on our side.
Are you using the latest release version?
What OS are you running on?

When creating a new Ozone project and opening a corresponding elf file Ozone expects that the output file path or name will not change.
Sometimes projects need to be moved. To keep them portable you can use function: Project.AddPathSubstitute

I'm not sure what you mean "path or name will not change" -- I'm not moving anything. I'm literally running make, and then loading the .elf file from (PROJECTDIR)/_build, with the source in (PROJECTDIR).

Quoted

These commands are Project.AddSearchPath() and Project.AddRootPath(). There are no useful examples on how to use these commands, and when I guess at it I don't get an error, but I also don't see Ozone try to look for the source.

The prototype information in the manual of the functions should give you enough information to get going. These functions expect a const char*. So that is what you give them. Simply your path you want to add with quotation marks "C:/Example/Path".

Sure... and I run that and ... nothing happens. If I specify a completely nonsensical path, I get no error. I have no feedback that the command has been processed and that that path has been added to the search path. My source does not appear (the "Source Files" window still shows "No Source Files"), no feedback at all. This is what I mean by extremely poor documentation.

I mean I get it. I'm a developer with over two decades of experience. I know that what is plainly clear to me may not be for someone using what I've designed. This is what your customers are experiencing with your software. The documentation needs a really good scrub with a technical writer who is NOT familiar with your tools so they can run the commands, use the software and see where the documentation is lacking.

This is a big ask, I know. I am thankful that Segger has given us such powerful tools -- I stayed away from proprietary Segger hardware and software for years -- I am in love with them now and recommend them to everyone, but this aspect (documentation) is very much lacking.

Quoted

One complaint I have about Segger's tools in general (JLinkExe, Ozone, JLinkGDBServer, etc.) is the complete lack of *useful* documentation for command line options or, in the case of Ozone, useful documentation on the Console commands.

We gladly take feedback about our products and documentation but this is the first time we hear that our documentation is disliked in general.

These forums have lots of examples of people saying that the documentation is lacking. Please take this criticism as a desperate plea from your loyal users that we want to use your products more effectively, but are stymied by the terse documentation and general lack of feedback from the tools (not from the support here, but from the tools themselves, see my comment above about what happens when I actually use Project.AddSearchPath().

Quoted

Why isn't there a --help command line option which documents all command line options for these programs, and how does Segger expect people to use the Ozone console without complete documentation on the commands available in the console?

Ozone is a GUI debugger. CL is only supported to e limited extend as Ozone already has a powerful scripting interface that makes CL options mostly obsolete.
Should you find an Ozone script function not documented feel free to contact us and we will take care of it.

My comment was about JLink.exe (and JLinkExe on OSX) -- where do I find ALL of the command line options and GOOD descriptions of what they do? Where do I find the existence of -SelectEmuBySn, for example?

If I can invoke a program from the command line, there should be a --help option which gives me a full list, defaults, etc.. These options should not be easter eggs that your users must hunt for. Even a terse list with defaults with --help would be useful, because then we know what to search for in the documentation, which could then have a FULL description, maybe examples where necessary, etc. It also helps for searching for answers on this forum or on the internet in general.

Quoted

PS - the code tag should not be swallowing carriage returns; I should be able to paste output from a terminal window or source de without adding double-returns between every line

This was not reproducible on our side.
Are you using the latest release version?
What OS are you running on?

Not with Ozone, with this very forum I'm typing this response on.

If I insert a code block and type "1 2 3 4 5" with one carriage return between them, it looks like "1 2 3 4 5" (i.e. the newlines are swallowed/converted to spaces. I'd expect this to happen outside of a code block, but within a code block I would expect that the text I place to be reproduced without this "translation".

Example with one carriage return between numbers:

Source code

1

12345

Now, with two carriage returns between numbers:

Source code

1
2
3
4
5

1
2
3
4
5

Those two examples should look the same since they are both within code tags. If I paste the output from a command or some source code, I should not have to manually go back and insert an extra carriage return between lines.