Search Results

Hello, Thank you for your inquiry. Quote from icwiener: “When I now install Ozone v3.20a and remove v3.10j and then open the .jdebug file in the newer Ozone, the path is invalid but I do not get an error message. ” We will add this to the improvements list for Ozone. Quote from icwiener: “When I then save the file with File -> Save project as... the path is not updated, so it remains invalid. ” This is expected as the path is set only once during project creation via the project wizard. Quote fr…

Hello, Thank you for your inquiry. See here for more information: segger.com/products/debug-prob…nk/models/model-overview/ Best regards, Nino

Hello AQ, Thank you for your inquriy. Ozone offers all GUI commands also via console commands. For more information see the Ozone user manual chapter Action Tables and User Actions. Best regards, Nino

Hi, thank you for your feedback. I will forward it to the appropriate channel. Best regards, Nino

Hi, sure simply use the ticket form below and reference that ticket to this thread. Alternatively any video/image hosting website link works for us too. Best regards, Nino

Hello Markus, Well the compiler that generates the image of Project A will also generate the symbols file. We recommend to set up your Project A in Embedded Studio as well. Either have both projects in one solution or in separate ones. Now first build application A. In the output you will find the elf file. This you can set in Project B as the additional symbols file. Best regards, Nino

Hi, Ah, the running part was the key here The issue is reproducible and is added to our ToDo for improvements. Best regards, Nino

Hi, Thank you for confirmation. Quote from SEGGER - Nino: “If yes could you provide the footage showing the issue? ”

Hello, Thank you for your inquiry. Does this issue appear with the latest Ozone version as well? If yes which host OS are you running Ozone on? Best regards, Nino

Hello, Thank you for your inquiry. The issue was reproducible and will be fixed accordingly. Sorry for any inconveniences caused. Best regards, Nino

Hello, Thank you for your inquiry. The reported behaviour was not reproducible. Could you give the latest Ozone version a try and see if the issue persists? If it does which host OS are you running on and could you provide a quick video showing the behaviour? Best regards, Nino

Hi, Thank you for your inquiry. Do you see the same behaviour in the latest Ozoen version? If yes could you provide the footage showing the issue? Best regards, Nino

Hi Markus, Sounds like a bootloader + application setup. In such case you can set the symbols file of Project A via project option Debug Symbols File in Project B, where up to 4 additional symbol files can be added. If you are looking for professional bootloader software we recommend emload: segger.com/products/field-upgrades/emload/ Best regards, Nino

Hi William, Thank you for your inquiry. While building on one system and debugging on another is usually not the most common use case you could try the following project option: Project Options -> Compiler -> Supply Absolute file Path = No Does that improve things for you? Best regards, Nino

Hi, Thank you for your inquiry. We added this request to our feature wishlist but we can't name any fixed timeschedule for this at the moment. Best regards, Nino

Hi, Thank you for your inquiry. Try Tools->Preferences->General->Source Viewer->Tab spacing->4 That should do the trick. Could you verify? Best regards, Nino

Hi, Thank you for providing the example project. With it the behaviour was reproducible. However Ozone acts correctly as the compiler does multiple optimizations here e.g. the LDRB R3, [R5] of source line 123 reused or the LDR of the GPIO registers is also reused from multiple different c source lines. This grouping of instructions to source file is done by the compiler and Ozone simply displays it. Comparing it to the behaviour of the other debugger you use in your video it appears that debugge…

Hello, Great to hear. This thread will be closed now. Best regards, Nino

Hello Dean, Thank you for your inquiry. Such an issue is not known to us. Do you see the same behaviour with the latest Ozone version 3.20a as well? If yes could you provide your example project for reproduction? Best regards, Nino

Hi Neculai, the compiler behaves correctly. The compiler is simply allowed to do that for const variables like you are using them. For the compiler const tells him this is a variable that will never change. So the compiler may place and set this value anywhere and treat it similarly like a define. The compiler does not know that you will do a flash erase at some point and the value will still correctly be replaced to 1 instead of the erase value. Instead you need to access the variable via e.g. …