Search Results

Search results 1-20 of 23.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Fair enough. The workaround basically is what I built myself. The disadvantage of using such a solution is that the extra hardware spoils the power profiling, so I'll just use the good'old 1 Ohm resistor and oscilloscope.

  • Ah, thanks for the heads-up. Will I still be able to see power consumption and voltage levels through this webserver? Also, thanks for the pointer to the power profiling features from oZone. I'll sure play around with it when I find some spare time! It is a pity the probes provide 5V Vcc only. I think it's safe to assume most (if not all) modern low-power designs require lower voltages (my hardware for example will run from a single CR2032 battery once it goes into production - the nRF52 and the…

  • Hi Nino, The latest and greatest v6.44 "suffers" from the same issue. It's no biggie since it's clear that either there's just a decimal point missing or there's a mismatch in unit of measure of course, it's just silly. Quote from SEGGER - Nino: “The J-Link software version you are using is quite old, could you try the latest one and see if the values improve? ” Anyway, 50 uA accuracy would be good enough for daily testing and power optimisation.

  • I'm feeding my target hardware from the J-Link Pro when debugging. The 5V output is regulated down to ca. 3V using an LM317T. The hardware connected to it is known to peek at ca. 10 mA. However... the J-Link Control Panel however says: forum.segger.com/index.php/Att…e60fe08a128d1d6f2688bebb8 Yes, it really says "18161 mA". That's 18A and a continuous current of 6.2A. Whoa! I guess it is using smoke signals inside the processor core! (hint: there's a couple of decimal points missing). On a more s…

  • RTT slow not usable anymore

    jev - - J-Link/Flasher related

    Post

    I had this same problem, see [ABANDONED] RTT Viewer 6.40 slow? (never got a notification from the forum software therefore I had not seen it was answered). We noticed the behavior depends on the host machine in use. We had this problem on several laptops and one desktop, all running Windows 10 Pro. In the end, we found a single machine (some HP laptop) where RTT ran sluggish / slow on 2 of the available USB ports but ran fine on a third one. Unfortunately, that specific laptop belongs to a custo…

  • Huh, sounds like it doesn't take the settings from sdk_config.h. do you define USE_APP_CONFIG by any chance? Let's check if something weird is happening: 1. Load your application in the SES debugger. 2. Set a breakpoint on _DoInit. 3. Run until the app hits this breakpoint 4. Set a new breakpoint on the end of the function. 5. Continue execution until the app hits this breakpoint 6. At this second breakpoint, open a Quick Watch on p 7. Drill down to aUp and aDown as shown below What are the valu…

  • Okay, I'll answer this myself In the SES debugger, you can actually read from files that will be opened on the host. Don't know if it'll work from oZone too, too lazy to try out. Note: the library does not contain freopen() and "stdin = fopen( ... )" did not really do the trick - no redirected stdin.

  • Quick question to which I could not find an answer: is there a hosted filesystem simulation in SES? I would like to execute a script that contains timed simulation stimuli where the script is stored on an RTT host.

  • Check the blocking mode used in RTT: in sdk_config.h, the macro SEGGER_RTT_CONFIG_DEFAULT_MODE decides what should happen when the RTT buffer is full (not cleared by your J-Link). I bet it is set to "2" ("BLOCK, Wait until there is space in the buffer"). Switch to a non-blocking mode and recompile.

  • 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…

  • [SOLVED] oZone reset behavior

    jev - - J-Link/Flasher related

    Post

    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!