Search Results

Search results 1-10 of 10.

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

  • Hello Nino, I've tried the version 3.10i -- the original problem with the variable 'value' has been fixed for me. Kind regards, Vadim

  • Hello Nino, I can reproduce it with NordicSemi SDK v16 on nRF52 DK board. It has on-board Segger J-Link. The project I used is nRF5_SDK_16.0.0/examples/ble_peripheral/ble_app_blinky Makefile: nRF5_SDK_16.0.0/examples/ble_peripheral/ble_app_blinky/pca10040/s132/armgcc/Makefile I've changed the optimisation flags there to OPT = -O0 -g3 and ran make from the directory where the Makefile is. I have also noticed that value is not the only affected variable. If a variable is named pc, or lr, or r0, it…

  • Hello, The only SEGGER-related file is Ozone project file, see attached. I can not attach the project source files for legal reasons. Kind regards, Vadim

  • Hello, The expansion indicators are always shown in Source window after start of Ozone. Steps to reproduce: 1. Start Ozone 2. Tools -> Preferences -> General -> Source Viewer -> Show expansion indicators -> set to "no" Expansion indicators will disappear. 3. Close Preferences. 4. Exit from Ozone. 5. Start Ozone. Expected behaviour: -- Expansion indicators should not be displayed. Actual behaviour: -- Expansion indicators are displayed. Host: xubuntu 18 Ozone: V3.10g Kind regards, Vadim

  • Hello, The display format of a variable named 'value' can not be changed, at least in Local Data window. Steps to reproduce: 1. Add the following function to your project, add a call to the function. Source Code (7 lines) 2. Compile, run on an ARM target. 3. Step into the function. 4. In Local Data window: -- select variable 'value', press 2, 3, 4 -- right click -> Display As -> Hex, Decimal, Binary Expected behaviour: display format of the variable 'value' should change accordingly. Actual beha…

  • Hello Nino, I think I know what is going on. Quote from SEGGER - Nino: “The reported behavour usually happens when Ozone can't find the source files at the paths that are referenced in the elf file. ” Attached is the screenshot of two windows: Disassembly and Call Stack. The breakpoint is at main() because of VAR_BREAK_AT_THIS_SYMBOL. It was called from _mainCRTStartup which is located in GCC's ~/bin/gcc-arm-none-eabi-9-2019-q4-major/arm-none-eabi/lib/thumb/v7e-m+fp/hard/crt0.o file. Which, in t…

  • Hi Nino, I am using nRF52-DK board PCA10040 and nRF SDK 16.0.0 . The SDK is installed into the directory ~/work/nRF5_SDK_16.0.0 Any example in the SDK will work, let's use examples/ble_peripheral/ble_app_template . This directory contains main.c and here the ozone.debug* files are located: Source Code (11 lines) Ozone project file has the only function: C Source Code (11 lines) To build the project and start Ozone: Source Code (4 lines) Now, when I connect to the target (F5) and on every reset (…

  • Hi Nino, Thank you for your reply. Unfortunately, it does not help. First, I have added Project.AddPathSubstitute to my existing project file. Disassembly window still pops up on reset. Then, I have created the new project using the wizard. Nope, the same. I am using arm-none-eabi-gcc. The elf file is not stripped, so all the path information is there -- Ozone properly opens the file with main() function. Anything else I could try? And while I am fiddling with the .jdebug file, I have spotted an…

  • Hi, Before I submit the official bug report, I would like to ask here. Every time I reset the target (with F4 key or Debug->Reset menu) the Disassembly window opens up. But I don't need it! I've got all my necessary windows, Source, Data, Call Stack, etc, all open and properly placed. And yet Disassembly appears, which I need to close. Or, if it was already opened, it pops to the front. This is extremely annoying. I tried to add Window.Close("Disassembly"); to different hooks in my Ozone.jdebug …

  • Quote from nicolo.olivotto: “It seems like that the lines of code are not executed in the expected sequential way. The highlighted green line move up and down without following the istructions flow. ” Hi Nicolo, That's because of compiler doing its best optimising the code, -Os option. Also, instead of -g option it is better to use -g3 : you can see the values of enums and macros in the debugger. Hope this helps, Vadim