[ABANDONED] building firmware on windows with msys2 (cygwin), ozone can't find source

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] building firmware on windows with msys2 (cygwin), ozone can't find source

    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:

    Source Code

    1. $ arm-none-eabi-readelf.exe -a _build/usbhost_blank.elf -W | grep FILE
    2. 12: 00000000 0 FILE LOCAL DEFAULT ABS _build/startup_nrf51.os
    3. 25: 00000000 0 FILE LOCAL DEFAULT ABS c:/msys64/home/akohlsmi/arm-gcc/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m/crt0.o
    4. 29: 00000000 0 FILE LOCAL DEFAULT ABS system_nrf51.c
    5. 33: 00000000 0 FILE LOCAL DEFAULT ABS atcproto.c
    6. 55: 00000000 0 FILE LOCAL DEFAULT ABS main.c


    (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)

    The post was edited 3 times, last by akohlsmith ().

  • Hello,

    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

    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".

    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.

    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.

    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?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

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

    SEGGER - Nino wrote:

    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.

    SEGGER - Nino wrote:

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

    SEGGER - Nino wrote:

    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.

    SEGGER - Nino wrote:

    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. 1
    2. 2
    3. 3
    4. 4
    5. 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.


    Regards,
    Andrew

  • Hello,

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

    How did you create the Ozone project? Did you create it and then move it around? Did source files or the output file change path or filenames?
    In all these cases Ozone won't know where the files are located and the path functions need to be used. Or you can simply recreate the Ozone project.
    If you are certain that nothing changed make sure that your compiler settings have no source information disabled. Otherwise Ozone won't be able to resolve the linked source file and will have only disassembly information.
    Source files are only not "found" when the source file window in Ozone lists them with a "warning" sign next to them and you get a warning printed in the Console. If they are not listed at all the they are not part of the output file information.
    If you are using GCC make sure option -g is set and optimization is disabled.

    These forums have lots of examples of people saying that the documentation is lacking.

    So far all these inquiries have resolved in either user mistake due to not reading the manual, incomplete documentation which has been added by us after requests or being a device specific problem that will not be part of our manuals but our wiki page: wiki.segger.com/Main_Page
    If users can't find what you are looking for in these two documentation sources they can contact us of course.

    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?

    J-Link user manual (UM08001_JLink) section 3.2.2.10 -SelectEmuBySN.

    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.

    We disagree, all information can be found in our documentation. Adding a --help function will double the workload when updating the documentation for a feature that is rarely used.

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

    OK, understood now. Thank you for your suggestion. We are currently in the process of moving this forum to another platform which should not have this issue anymore.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

    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).
    How did you create the Ozone project? Did you create it and then move it around? Did source files or the output file change path or filenames?
    In all these cases Ozone won't know where the files are located and the path functions need to be used. Or you can simply recreate the Ozone project.
    If you are certain that nothing changed make sure that your compiler settings have no source information disabled. Otherwise Ozone won't be able to resolve the linked source file and will have only disassembly information.
    Source files are only not "found" when the source file window in Ozone lists them with a "warning" sign next to them and you get a warning printed in the Console. If they are not listed at all the they are not part of the output file information.
    If you are using GCC make sure option -g is set and optimization is disabled.

    I am using the project creation wizard, and using the project (connecting to the target) immediately after the wizard finishes. I am not moving anything, and I'm not modifying any files in the directory tree. This isn't a "the project moved/changed and Ozone is confused" -- this is a "Ozone just created a new project and can't find the source".

    My CFLAGS are correct, and dumping the ELF objects verifies this. In fact, Ozone can see all the functions and knows what addresses they are at, but the source file window is empty. Further, the way the manual describes how to add source files does not exist in the GUI.

    SEGGER - Nino wrote:

    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?
    J-Link user manual (UM08001_JLink) section 3.2.2.10 -SelectEmuBySN.

    Thank you. I must be blind. Please accept my apologies regarding the lack of documentation on the command line options.
    Images

    • nosource.png

      72.6 kB, 719×1,045, viewed 832 times

  • Hello,

    Thank you for providing additional information.
    I am using the project creation wizard, and using the project (connecting to the target) immediately after the wizard finishes. I am not moving anything, and I'm not modifying any files in the directory tree. This isn't a "the project moved/changed and Ozone is confused" -- this is a "Ozone just created a new project and can't find the source".


    That sounds really strange. I talked to my colleagues and it seems that cygwin under windows tries to simulate Linux paths for sources which could lead to said problems.
    Can you send a screenshot from the Source Files window that shows the paths? Do they look somewhat unusual for Windows?
    Could you send us an example elf file to reproduce the issue?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Sorry for chiming in but

    SEGGER - Nino wrote:

    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.
    We disagree, all information can be found in our documentation. Adding a --help function will double the workload when updating the documentation for a feature that is rarely used.
    here I heavily disagree! On the command line it's more than common to type CMD --help to get at least a brief overview over the most important arguments (think at your customers using Linux). I doubt such a feature is rarely used as I find myself typing JLinkExe --help quite often, then cursing because it's not supported. I also doubt it will double the workload when updating the documentation... and even if it does, considering the time each user needs to find the JLink documentation (I don't have it open all day) and locating the relevant part in it compared with a simple JLinkExe --help it's worth the effort on your side.
    So please reconsider your policy regarding the a very useful feature...
    thanks

  • RE: building firmware on windows with msys2 (cygwin), ozone can't find source

    akohlsmith wrote:

    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.
    Strange we do the same here. On windows we also use msys2 to have mostly the same environment than on Linux but we don't habe the issue you described. Ozone just works...