Search Results

Hello, Thank you for your inquiry. Which version of Embedded Studio are you using exactly? Do you see the same issues in the latest version as well? Best regards, Nino

Hello, Thank you for your inquiry. In Ozone you can automate any action that you can do via the GUI. wiki.segger.com/Automated_Tests_with_Ozone Ozone can then be started via the command line and your Ozone project which contains the automation steps will simply be run. But this won't work on a headless system as Ozone requires a GUI. An alternative for automated tests via command line would be J-Run: segger.com/products/debug-probes/j-link/tools/j-run/ Should both tools not fit your needs exactl…

Hello, Thank you for your inquiry. Did you follow the following guide? wiki.segger.com/Use_SystemView…temView_using_.22tasks.22 There it says the following: - Next SEGGER_SYSVIEW_OnTaskCreate() needs to be called for each "Task" function. We recommend creating a helper function for this task e.g. SYSVIEW_AddTask in the example project. Did you take care of that in your example? Should that still not work could you provide a simple example project that shows this behaviour? Best regards, Nino

Hello Gabriel, Thank you for your inquiry. Yes you can do that. Per default SystemView uses channel/buffer 1 for communication and RTT Viewer per default scans channel/buffer 0. Just make sure not to use the same channel for both. Best regards, Nino

Hello Jernej, Thank you for your inquiry. In Embedded Studio you can handle the ROM Bootloader via the project settings directly as described here: wiki.segger.com/Bootloader_Handling_In_Embedded_Studio Best regards, Nino

Hello, We were able to identify the cause of the issue and it will be fixed with the next SystemView release. To get notified automatically when it becomes available we recommend to subscribe to our release notification mailinglist: segger.com/notification/subscribe.php?prodid=7,204 As a workaround we recommend to use older SystemView versions for now. Best regards, Nino

Hello Luca, We received your inquiry via our support system in parallel. In future we recommend to use only one contact channel at a time to avoid information being lost between channels. To avoid this this thread will be closed now. For completeness for anyone that stumbles upon this thread. The following answer was given via our support system: " Generally it is recommended to only use the cable that is shipped with the J-Trace Pro as every cable we ship is tested to fulfill the necessary mini…

Hello Julien, Thank you for your inquiry. According to the STM32WB reference manual only the STM32WB55 series has an ETM + TPIU. So if you are using any of the smaller variants instruction tracing will not be available. But if you have a STM32WB55 you can trace it if your board implements the necessary trace connector: wiki.segger.com/UM08001_J-Link…2FSWD_and_Trace_connector Quote from juliengros: “Are there any board design recommendations besides those (wiki.segger.com/Trace_board_design_recom…

Hello, Please note that discussing J-Link SDK API in public is a license violation. We have removed the offending part from your text and will close this thread now. For J-Link SDK support please use our official support channels as explained in my signature. Best regards, Nino

Hello, Thank you for your inquiry. You can dump the raw trace data to one or multiple files since November 2020 with the following command string: wiki.segger.com/J-Link_Command_Strings#TraceFile So you can analyze the data dump yourself and offload this to some server or similar for bigger data dumps. Loading the saved data into Ozone is not yet supported but is planned. However as this is a bigger task as making this work usable for customers without huge loading times or laggy UI is quite the…

Hello, The doxygen issue is not fixed yet but on our ToDo. We do not have a fixed timeschedule for this yet. Regarding the code outline issue with namespaces. This is reproducible and should be fixed in the next Embedded Studio release. Best regards, Nino

Hello, Thank you for your inquiry. Release mode usually includes some kind of code optimization. Please note that with code optimization active debugging becomes oftentimes impossible and the code referencing of our debugger is a complete guessing game. So your Breakpoint that you set on some function could be in reality somewhere completely else in your optimized application. So first for debugging we recommend to use the debug build with code optimization disabled. Does your application work n…

Hello, Thank you for your inquiry. Currently this is not possible as we are using the LLVM indexer for this task. But it is on our wishlist to improve this behaviour, but we do not have a fixed timeline for this yet. Best regards, Nino

Hello, Thank you for your inquiry. Such an issue is not known to us. Some svd files are written in a very nested manner so it is possible that it might take for some of them more resources than usual to unroll them. Could you share the svd file for reference? Best regards, Nino

Hello, Thank you for your inquiry. The doxygen comment stuff looks similar to what you reported here already: [SOLVED] Some feedback for Embedded Studio Correct? If so, it is still on our ToDo to improve this. Quote from Masmiseim: “You can drag n’drop code files out of the Embedded Studio main Window, which creates a new window. This is a very helpful feature which allows to have multiple code files open in parallel, but the new window is not snappy. If this window is moved to the edges of the …

Hello Max, no, you just wrap the malloc etc. calls directly on high level. Do not overwrite standard functions if not necessary. So you would write e.g. C Source Code (7 lines) Best regards, Nino

Hello, Thank you for your inquiry. Unfortunately it is not that simple. This is a problem that comes up with the Arm AEABI and with C++ mangled names ("exactly what is a uint32_t?"). '%u' should not be used for a uint32_t, you should use PRIuLEAST32 or PRIdLEAST32 from <inttypes.h>. Arm confuses the issue with the AEABI defining that 32-bit data are "unsigned" and "int". The C RTABI document and the AAPCS document do not discuss uint32_t, and nor does the C++ RTABI which, is more important here.…

Hello, Quote from _frank_: “If I understood this correct you mean the Segger GDB server which supports openOCD/pyOCD debuggers. ” No. In this context Embedded Studio is the GDB Client. The GDB Server is from openOCD or pyOCD. We have a universal GDB Client interface in ES, so you can technically hook up any debug probe that has a GDB Server to it. The J-Link GDB Server on the other hand is its own piece of software and has nothing to do with ES. It is simply our GDB Server that we ship with J-Li…

Hello, Quote from _frank_: “This is exactly what I needed. I overlooked this property until now - but to my defense, the number of setting items is a bit overwhelming ... ” Great to hear. Yes the number of options is quite something on Embedded Studio Quote from _frank_: “I'm using mostly Linux, and I suppose you mean a GDB server from ST, which needs to match the host OS. While ST's Cube IDE somewhat supports Linux, I am not sure if I want to go through the hassle - to say the least. While IMHO…

Hello, Thank you for your inquiry. Quote from _frank_: “The ICDI (from TI, e.g. used on their Launchpad boards) is not and probably will not be supported, right ? ” Not supported. Correct. Quote from _frank_: “There is such a conversion J-Link firmware for the LPC-Link2. I suppose it does not support the older version, called "LPC-Link". ” Correct. Only LPC-Link2 is supported: segger.com/products/debug-prob…other-j-links/lpc-link-2/ Quote from _frank_: “But does this firmware support the standal…