Search Results

Search results 1-11 of 11.

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

  • We are successfully able to set breakpoints when the processor is running using the J-Link Ultra probe with this version information. Unfortunately the J-Link Ultra (not Ultra+) is not available for sale. ARM RDI 1.5.1 -> ASYNC RDI Protocol Converter ADS v1.2 [Build number 848]. Copyright (c) ARM Limited 2001. SEGGER J-Link RDI DLL V5.00c, compiled Jun 11 2015 11:41:06 SEGGER J-Link ARM DLL V5.00c, compiled Jun 11 2015 11:40:27 Firmware: J-Link Ultra Rev.1 compiled Dec 3 2013 14:27:53 Hardware: …

  • It turns out I was wrong, it is not an ULTRA+, but an Ultra, here is the version information. I need to get approval before uploading the logs. The Ultra has much older firmware/HW revs. The Ultra also does not appear to be for sale anymore. The J-Link Ultra version information ARM RDI 1.5.1 -> ASYNC RDI Protocol Converter ADS v1.2 [Build number 848]. Copyright (c) ARM Limited 2001. SEGGER J-Link RDI DLL V5.00c, compiled Jun 11 2015 11:41:06 SEGGER J-Link ARM DLL V5.00c, compiled Jun 11 2015 11:…

  • We are using J-Link PLUS and J-Link Ultra with the ARM AXD debugger over the RDI interface on Windows 7. Our processor is an Arm9 The J-Link Ultra works great with no issues, however when using the J-Link PLUS we get processor faults which cause our program to stop executing. Are there any differences between the models which could cause problems? This is not a high speed processor, so I did not think the interface speed would matter.

  • Attached is a simple project, but I don't think the project matters. Breakpoints work OK if the AXD debugger is paused, but when the debugger is running you cannot set a breakpoint. The old AXD debugger with the multi-ice pod allows breakpoints to be set when the processor is running. We have a legacy project, and have been trying to avoid upgrading to DS-5. We did try the J-Link debugger, but unfortunately our project uses a large number of small separate images (axf files), and I think the J-L…

  • We are using J-Link PLUS with the ARM AXD debugger over the RDI interface on Windows 7. Our processor is an Arm9 We are not able to set any breakpoints when the processor is running. When using the old Multi-ICE pod with AXD we are able to set breakpoints when the (same) processor is running. In the SEGGER J-Link Control Panel we have set the "Modify breakpoints during execution" to Allow, but it does not seem to have any effect.

  • The problem is fixed when we upgraded eclipse. We are using GDB through eclipse CDT, and the old version had CDT 7.0.1.2010... and we switched to CDT 8.3.0.2014... After the switch we never see a reset on the JLINK GDB server. My best guess is that the older CDT was sending a signal (through arm-none-eabi-gdb) to the JLINK GDB server which was causing the reset, and the new version does not send any signal. The problem occurred (with the older CDT) when we we pressed the terminate button on the …

  • I know this is an old thread, but I am having the same problem with windows 7 64 bit . Can someone at SEGGER tell us if the RDDI connection does not work with DS5 on 64 bit windows? I did have success using the GDB server with the DS5 debugger on windows 7 64 bit. I selected a processor with a gdb server, it was not our target processor, but at least an arm processor. In the DS5 debug configuration Connection tab, I selected NXP, LPC3240->Linux Application Debug->Connect to already running gdbse…

  • We are testing using J-Link PLUS with the J-Link GDB server on Windows 7. We are using Eclipse CDT and arm-none-eabi-gdb.exe to connect to the server. Debugging works OK, however when we exit (or close) a debug session our processor locks up. On the J-Link GDB server the log indicates "Reset target CPU..". I think the reset is killing our processor due to our specialized HW. Is there any way to disable the reset of the target CPU from the J-Link GDB server? Our HW setup does not allow for a rese…

  • I was able to change this settings file with the changes described C:\Users\my_user_name\AppData\Local\VirtualStore\Program Files (x86)\SEGGER\JLink_V496b\Default.jlinksettings Now the Target Device Settings is not displayed when AXD is started.

  • You are correct and none of the 3 options are implemented for AXD. Although AXD does not allow anything to be passed to the dll, there is a line in the JLINK log file showing this JLINK_ExecCommand("ProjectFile="C:\Program Files (x86)\SEGGER\JLINK_V496b\Default.jlinksettings"", ...) I think we can just edit this default config file and set the device to one we use, such as DEVICE="ARM9"

  • We are using J-Link PLUS with the ARM AXD debugger over the RDI interface on Windows 7. Currently when we start the AXD debugger, the Target device settings window is displayed and we have to select the processor device and then press OK. Is there any way to set this in an init file, so the window is not displayed every time AXD is started? We have a large number of batch files that start AXD and run scripts and it would be nice if we did not always have this window pop up before the script is e…