Search Results

Quote from SEGGER - Nino: “If I now go to my project settings ” At that exact point you start "hiding" the setting in a vendor-specific way because one needs the IDE installed and up and running to see it. I can't see the definition in the sourcecode, I can't see 'm in a makefile (note: "make" is a defacto standard, every engineer should be able to read makefiles IMHO). If I want to add definitions, I can't just take out vi or emacs (insert your favorite editor here) and create them - I need to …

Unfortunately, the solution you mention is merely a method that still hides the macro definitions somewhere in the IDE. We'll just have to live with it I guess, if there just is no way to do pre-include the header we'll just have to document them in such a way they won't be "forgotten about". Fair enough. Thanks for your help anyway Nino!

Quote from SEGGER - Nino: “1: It is not necessary to port IAR projects if you are using Nordic SDK. The latest SDK already has working Embedded Studio projects. ” Thanks, but that is not the issue. I have a real-world project that was set up in IAR and need to be worked on off-site. It uses some language extensions and some things like said stdatomic that is supported by native GCC for ARM. The remote party uses SES, therefore I have to put a porting effort in this. Most of it is easy, handled b…

I am trying to port a project that was written in IAR Workbench for ARM to Segger Embedded Studio. This project was built for an nRF52832 and compiles well with both, IAR and GCC toolchains. According to NordicSemi, the version that is supported by their nRF5 SDK (15.2) requires SES 3.40. So, I installed SES 3.40 for ARM. Additionally, I installed the nordic nRF package. I run into a couple of issues that have to do with toolchain configuration though. 1) In the project, several settings have be…

I'm using RTT viewer to download realtime samples from my hardware (nRF52832, connected through a J-Link Plus, SWD at 4 MHz). It outputs 72 samples per second, written in ASCII. RTT Viewer v6.40 doesn't seem to be able to keep up, whereas v6.32h (which I used before) had no problem whatsoever. Is this a known issue? Was it intentional somehow?

Thanks for the explanation. Unfortunately, no, I don't use any WFI and disabled power management (no sleep modes therefore). It's weird then that reducing SWD speed to low speed or disabling RTT makes things work correctly. I mean, the debugger still operates, even at 4 MHz. I enable RTT and *poof*, dead. Slow SWD down to 10 kHz and the system works again (albeight a bit slow).

We recently refactored our little nRF52 project. Removed FreeRTOS from the project and updated to the Nordic's SDK15. Since that time however I noticed RTT seems to have a pretty hefty impact on the system's realtime performance (which isn't very good already due to the softdevice running on it). As soon as I enable the RTT viewer (or oZone with RTT terminal enabled), bluetooth crawls down to a full stop. Apparently, RTT destroys the softdevice's timing somehow. The system is idle most of the ti…

Quote from SEGGER - Nino: “Regarding 1: Such an issue is not known to us. Could you provide the .elf file for reproduction?” Sure, see attachment. I took the BLE blink app from Nordic's SDK15, compiled for Nordic nRF52832 with an S132 softdevice. In order to reproduce my environment, you'ld need to flash the softdevice first (download the SDK from Nordic's website here, the softdevice is stored in ~/nRF5_SDK_15.0.0_a53641a/components/softdevice/s132, than load this compiled application through o…

Hey guys, I'm using oZone 2.56l on a Nordic nRF52832 connected by a J-Link Plus. Toolchain: IAR 8.11.2. I have two problems with this configuration lately: 1. On loading the generated .out file, I get messages from oZone: Source Code (3 lines) It still loads the objectfile correctly though, debug information as far as I can tell seems to be correct and it stops at main as I expect it to. 2. When running, the target stops somewhere in Nordic's softdevice, always on the same address and it won't c…

I use oZone with a J-Trace for ARM Cortex-M on a Nordic nRF52832. When resetting the system, I see different behavior with tracing disabled, also different behavior on first start. It seems oZone just reads the start address from the ELF file and jumps to that address, is that right? Can I change this behavior so that it mimics a true cold reset (through the bootloader, using the MBR etc.)?

Okay, fair enough. I'll just have to work around the issue until it's implemented - hopefully soon!

I'm using oZone on a J-Link (well euhm... J-Trace to be honest) to debug an nRF52 system running FreeRTOS. I can't really step through the source because FreeRTOS swaps tasks on a timer interrupt and than crashes. Is there a way to disable interrupts from the debugger once it hits a breakpoint?

Thanks for your prompt answers Nino! Unfortunately, ETB selection results in continuous popups of "Driver" dialogs "Warning: ERROR: Failed to stop trace" at every command I execute (step, reset, everything really). Unfortunately, we have no support contract with IAR (we're just a small startup that can't justify the extra expense there) so basically we're euhm... you know. Is there anything Segger can do to push this issue a bit harder to IAR? I know IAR has its own debug pod but it never hurts …

I have a project that was built using IAR's Embedded Workbench. The target hardware contains an Nordic Semi nRF52832 from which only GND, Vcc, SWDIO and SWCLK are available on the outside. Flash and debug always worked flawlessly on this hardware using a simple J-Link but that one is no longer available to me. I do have a J-Trace Pro for ARM Cortex-M available though. The problem I'm facing is that IAR's debugger won't play nice with J-Trace. It flashes correctly but once the debugger is started…