Search Results

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…

Hi Steve, Thank you for your inquiry. Such an issue is not known to us. Could you please provide more information regarding the issue? Which host OS are you running? Which version of Embedded Studio are you using? Are you using any display scaling features? Best regards, SebastianB

No worries, great to hear that you are up and running! We will consider this case as solved, happy tracing!

Hi, Thank you for your inquiry. At first glance it seems like the description file could not be found when using MacOS. Are there any messages regarding this in the log window? In case it cannot be found the expected path should be written there, so you may simply copy the file to the expected location. Best regards, SebastianB

Hi, Thank you for your inquiry. Correct, the FreeRTOS kernel does not need to be patched anymore starting with version 11. Nevertheless the project still needs to be setup correctly to work with SystemView. Please take a look at our Wiki for all required steps as well as an example project: wiki.segger.com/FreeRTOS_with_SystemView Starting with FreeRTOS v11 all API functions may be traced, instead of a smaller selection as was the case with the older patches. Because of this some IDs are missing…

Correct, you need to supply your own UART implementation as the specifics are hardware-dependent. Happy coding! Sebastian

Hi, Thank you for your inquiry. By default RTT is used for any debug input and output. In case another I/O type should be used instead you may configure the Library I/O project option. You can find more information regarding this here: wiki.segger.com/Embedded_Studio_Library_IO Best regards, Sebastian

Hi Frank, Thank you for the analysis. As you have correctly seen these files are maintained by ST, and only included in the CPU package. We will notify ST of this bug, so it may be patched in a future release. Best regards, Sebastian

Hello, in case the recording works while the system is crashing (and the target can still be accessed afterwards) the recording should still show the corruption. But SystemView may not record everything fine enough. In such cases tracing may be preferable. RTT is only used as input here. As long as the idle time or crashing issue is part of the recording, it can be shown in SystemView. Best regards, Sebastian

Hello, in case your target does not support RTT, you need to save the data recording from the target to a file on the host system. This is explained in the manual here: segger.com/doc/UM08027_SystemView.html#Single_shot_recording In short, following steps are required: - Halt the application with the debugger when either the recording is done or the buffer is full - Get the RTT buffer address and number of bytes used (usually _SEGGER_RTT.aUp[1].pBuffer and _SEGGER_RTT.aUp[1].WrOff) - Save the us…