Posts by akohlsmith

I am seeing the exact same thing. OSX 13.6.2, 2019 Macbook Pro (Intel i7, 32G RAM). Tested with Ozone 3.22e, just downloaded 3.30c to test.

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

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.

*bump*

Any word on this? It's completely reproducible. Alternatively, is there a better way to contact Segger for support on this issue?

Quote from SEGGER - Nino

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

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

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

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

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:

12345

Now, with two carriage returns between numbers:

1
2
3
4
5

It's not an issue specific to the dev board; I was using the larger devboard to try to diagnose the problem. It's the "NRF51-Dongle" (Digi-Key part number 1490-1037-ND) that we first noticed the problem on.


I'm absolutely positive it can be reproduced on any J-Link using vcom.


Reproducing it:
- configure target to send a continuous stream of data to the Segger over UART (we are using 460800,N81 but baudrate should not matter). Make sure that target observes hardware flow control as required by the Segger
- Connect the segger+target to the Windows PC via USB. Our system is powered from USB so the Segger and target power up at the same time
- open serial terminal on the PC. We're using TeraTerm. Observe data coming from target through virtual com on Segger.
- close the serial port, observe that the CTS line from Segger to target will de-assert after 256 characters as Segger RX buffer is full
- open serial terminal on PC again. Observe that CTS does not assert, and never will until power is cycled.


These same steps on OSX or Linux do not result in the CTS from Segger to target being stuck, and downgrading the Segger firmware to "J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09" or earlier shows correct operation even on Windows.


I can provide a minimal test-case sample source+binary for the nRF51-dongle if it will help.

I oftentimes get this if I've protected the Flash on my Nordic nRF51822 designs. At least for me, in those cases, I manually use w4and mem32 to erase the entire flash, reset the ARM with the r command and then I am able to use the Segger high level functions.

I don't know if this will help in your case, but it might be worth a try.

excellent, thank you!

On Windows, it's easy to load two copies of Ozone (for multi-core debugging).

How do I do this on OSX?

I've got about a dozen copies of JLink on my system now.

The regression occured in the firmware shipped with 610b. The firmware shipping with 610a is good.

610b (CTS does not re-assert if the UART buffer is filled and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Sep 26 2016 11:30:32
610a (CTS will re-assert if the USB buffer is full and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09

This regression has been in the JLink releases for a very long time now. I hope this groundwork helps you create a speedy fix.

Another datapoint: JLink 5.10h (January 12, 2016) DOES NOT have this issue. I can start and stop the virtual COM connection as many times as I like and the CTS line to the Nordic does not get stuck.

I'm using the Nordic 400092 nrf51 dev board with an embedded Segger. The firmware on the Segger is "J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20".

I think there has been a regression in the J-Link firmware. I have been using these boards for *months* without issue, but very recently I've been seeing a case where the RTS line (from the SAM3U to the Nordic) will go high and stay high.

It's fairly easy to reproduce: Have the Nordic spew data to the Segger while the PC is reading from the virtual COM port, and then "disconnect" from the virtual COM port. The Nordic will continue to fill the Segger's UART buffer and then when that buffer is full, the Segger will de-assert RTS and the Nordic will stop sending.

However, if I connect the terminal program (Teraterm) to the virtual COM port again, RTS is *not* de-asserted. Cycling power tends to fix the issue until the next time the Nordic fills the Segger's UART buffer and the Segger de-asserts the RTS signal to the Nordic again.

This problem does not appear to happen on OSX or Linux, leading me to think that perhaps a recent Segger firmware update does not flush the SAM3U's UART buffer when the CDC DTR signal is asserted.

edit: I have downgraded the JLink firmware all the way back to March of 2017, and the same problem occurs with Windows. I have confirmed that SAM3U CTS assert/deassert works fine under OSX/Linux, but never re-asserts under Windows.

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:

$ arm-none-eabi-readelf.exe -a _build/usbhost_blank.elf -W | grep FILE
12: 00000000     0 FILE    LOCAL  DEFAULT  ABS _build/startup_nrf51.os
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
29: 00000000     0 FILE    LOCAL  DEFAULT  ABS system_nrf51.c
33: 00000000     0 FILE    LOCAL  DEFAULT  ABS atcproto.c
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)