Posts by SEGGER - SebastianB

Hello,

Thank you for your inquiry and providing the reproducer.
We have reproduced the issue in-house and will of course take a closer look.

Kind regards,
SebastianB

Hello,

Thank you for your inquiry.

We have reproduce the issue and will of course have a closer look.
A fix will be provided in a future Ozone release.

Please excuse any inconveniences caused.

BR
SebastianB

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 more information regarding the setup? What board is being used?

Best regards,
SebastianB

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):
https://wiki.segger.com/Get_a_License_…nductor_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, could you provide us with this snapshot?

Please note that bumping threads without added information is against forum rules. This is not a support forum but a community forum, there is no guarantee that you will receive an answer.
For more information see my signature.

Kind regards,
SebastianB

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 addresses but prepared for different positions.
The bootloader would then select the appropriate image to flash and boot to.
This removes the limitations regarding the position-independent code and simplifies the setup.

Best regards,
SebastianB

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: https://clang.llvm.org/docs/ClangFormatStyleOptions.html

The "Formatting Style" setting allows an easier selection to the predefined styles, e.g. Chromium, and also defines some custom styles.

2)
Based on the screenshots there are currently uncommitted changes in the V8.10d session, while V8.12 is in sync with the repository.
This is the intended behavior, as the file may not be removed while there are pending changes, and there is of course nothing to compare/revert to without modifications.

Best regards,
SebastianB

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/devel…gy/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:
https://www.segger.com/downloads/embedded-studio/

Best regards,
SebastianB