Search Results

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: “Quote: “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 si…

*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:…

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 t…

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 …

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 f…

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 so…