Search Results

Hello, We received your inquiry in parallel via our support system where your question was answered. Please do not use multiple communication channels for the same inquiry with us as this can cause lost information between channels and increases our average answering time. This thread will be closed now. For anyone else stumbling across this thread. Old packages can be found on our packages page: studio.segger.com/packages/ You can download them there and install them in Embedded Studio via Tool…

Hello, OK. Great to hear that you are up and running again. We will consider this thread as solved now. Best regards, Nino

Hello, Thank you for providing the example project. With it the issue is reproducible. It appears that the target device does not support background memory access for the memory area where the variable is located at. It reports that the memory read failed which returns the 0xaaaaaaaa value which is in decimal the 2863311530 that you see. That is why you only see the correct value when the chip is halted. It is simply a hardware limitation by the HPM6750. Best regards, Nino

Hello, Thank you for your inquiry. From the behaviour it appears that the variable is placed in stack which is probably not what you are aiming for. So instead try declaring the variable as static. Do you still see the issue then? If yes, could you provide a small example project for reproduction? Best regards, Nino

Hello Florent, Thank you for your inquiry. What is the S/N of the J-Trace Pro you are using? For trace to work and later not to work there is usually one of the following reasons: * The trace interface between target device and J-Trace Pro is unstable (e.g. due to board design) so it only works sometimes. * The target application reconfigures the trace pins or similar causing the loss of data. Here are our troubleshooting guides: wiki.segger.com/J-Trace#Trouble_shooting And here are some setup c…

Hello, Quote from Akito: “When i link the application at address 0x0, the unused functions are marked as executable code in Ozone and i have the warning mentionned earlier on them. It is as if Ozone is confused on the possible location of these unused functions since Ozone indicates that they are located on address that contains start up code. ” This is not confusion. Ozone simply displays what you configure in your elf file. This is correct behaviour. If what you configure is wrong, Ozone will …

Hello, Thank you for your inquiry. Currently no plans for official support. But you can always use an external gcc that supports the extension and call it with Embedded Studio: wiki.segger.com/Use_an_externa…hain_with_Embedded_Studio You can also debug such setups, just keep in mind that the disassembly might be incorrect for the unsupported extension instructions. Best regards, Nino

Hello, Thank you for your inquiry. The warnings mean that the assembly code from the FreeRTOS RISC-V port is faulty. Each function must be declared as one as follows: C Source Code (1 line) Best regards, Nino

Hello, Thank you for your inquiry. Quote from jmarcialis: “The -T option is not separated from the file path, hence the syntax error on the new project. Is this normal ? ” Yes that is fine. Quote from jmarcialis: “If not, how can I possibly edit this command or solve the problem ? ” Most likely the command is not the problem but the content of the linker script itself. You can switch to a more verbose output by chaning the view in the Output Window from Tasks to Output in the drop down and in th…

Hello, Thank you for your inquiry. SWO profiling is currently not supported by Ozone. It is on our feature wishlist. You can only do printf via SWO in Ozone. If you are looking to do SWO profiling with J-Link our IDE Embedded Studio can be used: segger.com/products/development-tools/embedded-studio/ wiki.segger.com/Configure_SWO_in_Embedded_Studio Best regards, Nino

Hello, Thank you for your inquiry. As the poster before me mentioned one reason is typically a optimized build being debugged. Make sure you have code optimization off and debug symbols active in your toolchain. Another hint is the warning sign in your screenshot. This usually indicates code that is generated on run time e.g. RAM code. Make sure that such areas are added to the instruction cache: wiki.segger.com/Ozone_Debug_and_Trace_with_RAM_Functions Best regards, Nino

Hello, Thank you for your inquiry. We received your inquiry via our support channel in parallel as well. To make sure no information is lost between channels this thread will be closed now. Please do not use multiple contact channels for the same inquiry as this will only cause extra workload on our side slowing down our response time. Best regards, Nino

Hi, it is generally recommended to power cycle a MCU when protection is enabled. This ensures on (most) chips, that the settings get active. Additionally this also ensures that the J-Link connection is reset as well Best regards, Nino

Hi Marco, Great to hear that you are up and running again. Case closed. Best regards, Nino

Hello, Thank you for your inquiry. As mentioned in the other thread, this is intentionally not public knowledge so I will drop you a PM. Best regards, Nino

Hello, Thank you for your inquiry. Your GCC toolchain should give you some elf output file. If you load that up in Ozone the assembly sources should be referenced automatically. Just make sure that you set compiler options so debug info is generated. Otherwise the source file reference might be missing from the resulting elf file. Best regards, Nino

Hi Marco, yes it is still on our ToDo but not with high priority. So we can't name any fixed release date. But it is not forgotten Best regards, Nino

Hello Marco, Thank you for your inquiry. Such an issue is not known to us. Which version of Ozone are you using? Do you see the same behaviour in the latest version? Does it happen with binary files only or also with elf files? Could you provide exact reproduction steps? I gave it a quick try and the ODR register in my example setup stayed expanded when reloading the project due to application change. Best regards, Nino

Hello, Thank you for your inquiry. Correct embOS is our own RTOS so the plugin would not work with other RTOS's. Generally it is possible to view RTOS info of any RTOS in Ozone. But you need to supply a plugin so Ozone knows where to look for task/thread information of your RTOS. For this Ozone has an open JavaScript based interface which you can use to create your own RTOS awareness plugin. How is described in the Ozone manual in chapters 6.3 and 7.10. Best regards, Nino

Hello, Which J-Link Ultra+ exactly? There are multiple hardware revisions. Could you share your serial number please? What target device are you debugging exactly? Continuous recording is possible. However there will be naturally gaps as the gaps are defined by your sampling frequency. You have set it to Max which is >10 kHz. But e.g. if you set it to 100 Hz it is expected that between each sampling point there is a delay of ~10 ms (for 10 kHz it would be 0.1 ms). There is some delta here as J-L…