Search Results
Search results 1-20 of 35.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Hi JulianR, Great to hear that you are up and running again. Happy debugging! Best regards, SebastianB
-
Hi JulianR, there have been some changes regarding the SVD handling in the most recent version. We were able to reproduce the crash with the provided file and will of course investigate the issue. Kind regards, SebastianB
-
Hi Adam, Thank you for providing the files and instructions! We were able to reproduce the issue on our end. We will of course take a closer look here and provide a fix in a future Ozone release. Best regards, SebastianB
-
Hi Andy, quick update: We were able to reproduce the issue. We will of course have a closer look and provide a fix in a future Ozone release. Thank you for making us aware of this! Kind regards, SebastianB
-
Hi ram.techen, Debugging bare-metal on this device is unfortunately not as straight-forward as with other hardware. Could you please additionally provide any other required files for this debug setup? At least the boot-image seems to be missing. Could you furthermore describe all required steps to get up and running? Thanks and best regards, SebastianB
-
Hi Oskar, In case the JLinkSWOViewer works correctly it should also work in Ozone without issues, when using the same settings. Did you configure all required settings described in section 5.12.2 of the User Guide? SWO is configured using the trace settings dialog. The correct settings are required for it to work. In case the auto configuration is used: Could you please check whether the issue persists when manually setting all fields? Should the issue not be resolved: Could you please provide m…
-
Hi Alex, As written, our CPU packages are based on the CMSIS DFPs and is using almost all of the information available therein. The Nordic SDK may include some of the required source files, but is still missing a lot of the required device information. Because of that it does unfortunately not suffice for this use-case. Best regards, SebastianB
-
Hi, Thank you for your inquiry. The Embedded Studio CPU support packages are based on the CMSIS packages provided by the device vendor. The nRF CMSIS package does not include the nRF54L series yet. We will have an eye on it and update the CPU package after the CMSIS package has been updated. Best regards, SebastianB
-
Hi fraengers, We have successfully reproduced the issue. At first glance this seems like it could simply be that a part of the chain is overloaded. This could be some buffer, the connection itself or even the host system. We will of course check whether we can improve this, but at this point we cannot make any promises. As a workaround lowering the sampling frequency and/or the J-Link connection speed reduces the load, stabilizing the data sampling. Best regards, SebastianB
-
Hi HARI, Thank you for your inquiry. On our Wiki you can find a FAQ that should resolve the reported behavior (see first question): wiki.segger.com/Get_a_License_…dic_Semiconductor_Devices Best regards, SebastianB
-
Hi, We tried to reproduce the issue using V3.38, but everything seems to work correctly. After the snapshot has been loaded the timeline window looks as expected, even after changing the time-scale. The "corruption" may be seen shortly while the snapshot is being loaded and the time-scale is at 2 or 5 seconds Otherwise it cannot be observed on my end. Could you check whether the issue still appears with V3.38? Can the corruption be observed even after the snapshot has finished loading? If yes, c…
-
Hi, Did you setup the project correctly for long long printing support? (Code > Printf/Scanf > Printf Integer Support set to "Long Long") "sprintf" does of course exist and may simply be used after including "stdio.h". Could you check whether the application was prepared correctly? Best regards, SebastianB
-
Hi, thank you for your inquiry. Which compiler are you currently using for assembler code? Only the unified syntax is supported when using the SEGGER compiler, meaning the divided syntax is not supported at this point. Switching to GCC should solve the error. Best regards, SebastianB
-
Hello, Thank you for the explanation! This would require the application to be built position-independent. This is rather unusual on embedded devices and does come with many limitation which have to be noted. The Project may be configured regarding this using the "Code > Code Generation > Relocation Model [segger-cc]" setting. For further information please take a look at the clang documentation. Alternatively we would recommend to instead always prepare and ship two images, both using static ad…
-
Hello, Thank you for your inquiry. 1) The built-in formatter is based on clang and as such supports all options available there. Previously most of these were listed each, but to support all current and future commands this was changed to the single "Formatting Options" setting. As written in the description, all available clang formatting commands may be used: clang.llvm.org/docs/ClangFormatStyleOptions.html The "Formatting Style" setting allows an easier selection to the predefined styles, e.g…
-
Hello, Thank you for your inquiry. The attachment unfortunately did not work, what is the exact error message? The issue may be related to an incorrect project configuration. We generally recommend to use a CPU support package when first setting up a project, as the project is then correctly prepared for your specific device. For more information take a look at our website: https://www.segger.com/products/development-tools/embedded-studio/technology/cpu-support/ Best regards, SebastianB
-
Hello, Thank you for your inquiry. Most likely the library I/O type is not correctly set in the project. Please take a look here for more information: https://wiki.segger.com/Embedded_Studio_Library_IO Best regards, SebastianB
-
Hello, Thank you for your inquiry. All older versions up until V4.10 may be found on our website: segger.com/downloads/embedded-studio/ Best regards, SebastianB
-
Hello, Thank you for your inquiry. I am not completely sure whether I understand you correctly. Could you please elaborate what you are trying to do? Are the applications in B and C simply mirrored or do they differ in some way? Should both applications be flashed at the same time or should only one be updated at a time? Is the increased safety related to the boot or the update process? In case both applications should be flashed at the same time you may set "Debug > Loader > Additional Load Fil…
-
Hello Lef, Thank you for your inquiry. As Frank correctly wrote the ELF format does include debug information, while binary and hex only include the image itself. Instead of using an external tool, the binary or hex output may also be generated directly in ES by using the "Code > Linker > Additional Output Format" project setting. In case the paths can still be read in the binary, the paths are part of the application itself, e.g. because of exception handling or macros like __FILE__. Please see…