Search Results

Search results 1-20 of 1,000. There are more results available, please enhance your search parameters.

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

  • As you did not change your tools, setup, SW versions etc. there are only 2 things left: 1) You have have a bad cable etc. that has bad/unstable connection to your HW 2) You have changed your application to enter low power modes that inhibit debugger connections reg. 2) Do you have the nRESET pin of the ST device connected to J-Link, so J-Link can control it? It is mandatory to make sure that J-Link can connect to your device, no matter in what state it is. - Alex

  • FYI: No need to use the beta version (V6.23a) but the latest release will also do (V6.22e) as it has been fixed there. However, glad to hear that you are up and running. Best regards Alex

  • Hi, Could you please provide a J-Link logfile of a failing session? What you provided is not a J-Link logfile but some IAR log output. J-Link logfile: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Best regards Alex

  • There are different sample applications shipped with the SDK, for different programming languages (C, Basic, C#, ...). Quote: “ Who programs in C / C++ anymore on Windows anyway??” I won't comment on this. Best regards Alex

  • Hello Tharon, We do not see any stability issues with the IP connection through the Remote Server. If you are seeing problems, we are always willing to help and interested in making our products better and more robust. So if you could describe a bit more on what actions you see the connection stability issues, it would help us to boil down the problem. May I ask you one question?: If things are really time critical and you are a commercial + professional J-Link user, why do you go through a foru…

  • Quote: “ EDIT: My fault, already had a lingering tunnel connection from another machine with this S/N... ” O.K., so to be correct: This is *not* broken in the ARM package and it was a user error. Correct? Best regards Alex

  • Hi, If this does not work, even the basic communication with the device does not work. Did you connect the reset pin of the MCU to the EDU Mini? Having the reset pin connected it mandatory for NXP Kinetis devices. Could you please check with an eval board? Does the eval board work as expected? Best regards Alex

  • Hi, Quote: “One week waiting here,” This is *not* a support forum, so there is absolutely no claim for support or even getting an answer directly from the engineers... Quote: “I still think fixing the IP errors / timeout issues without Segger's tunneling mode should be preferred ” Again: J-Link PRO and Remote Server are designed to be used in a LAN(!). Timeouts, reaction times etc. all is designed for being used in a local network. Connecting from a machine outside of the network, via VPN etc. w…

  • Hi all, We have found the problem. Will be fixed in V6.20a which is going online later today: segger.com/downloads/jlink/ We are sorry for all inconveniences caused. Best regards Alex Gruener - Product Manager J-Link

  • Hi, a stripped down project would certainly help. Quote: “But before that, can we somehow confirm that we aren't having problems with the programming cable?” Trying another cable? Quote: “We are now suspicious of it because gdb and Ozone both have some stability issues. JLinkGDBServer sometimes dumps a bunch of errors of how it couldn't access CPU registers in running state, and Ozone just displays an error that it can't read device status.” That indeed sounds like HW issues or evil software tha…

  • Hi, Quote: “ Is where any way to add a custom flash loader to the JLinkCommander?” Yes, there is: wiki.segger.com/Adding_Support_for_New_Devices This works for all SEGGER utilities: J-Link Commander, GDBServer, J-Flash, ... Please note that no support is provided by SEGGER, for custom flashloaders. Could you please let us know which device you are using (Vendor + device name) that your QSPI is connected to? It would help to check if there is a regression in the current version. Best regards Alex

  • Hi, Should have been part of V6.16d but unfortunately it was not patched in there (even though the release notes indicate that it has) due to an internal mistake. Will be part of V6.16e which comes during next week. Best regards Alex

  • Hello Edoardo, Sorry to hear that you are having problems with your J-Link. Quote: “I am clearly wrong in thinking there is a kill-switch that bricks our J-Link at some point after its warranty runs out, however I will never know, being you the only ones able to inspect J-Link firmware source code. We have a saying in my country -- "You sin in thinking bad about people, but, often, you guess right."” Wow, that's somewhat disappointing...First time I hear something like this in my now 10 years at…

  • Hi, No, J-Link command files / commander scripts are not able to receive arguments. What you could do in your bat file WEEPROM.bat: C Source Code (6 lines) Best regards Alex

  • Simple example: You can easily start multiple instances of J-Link Commander, each connecting to a different J-Link connected to the PC. Best regards Alex

  • Hi, Sounds like the trace timing on the device you are using is not good. If you have a J-Trace PRO, you can adjust the trace timing, to make things working even if the device is outputting trace data outside the trace spec.: segger.com/jtrace-pro-cortex-m-setting-up-trace.html (See troubleshooting area at the bottom) Please note that the adjustment of the trace timing is not available on the non-PRO version of J-Trace. What device are you using? (Manufacturer + device name) Best regards Alex

  • Hi Greg, The J-Link PRO was mainly designed for inside LAN debugging, so VPN connections may cause some trouble with internal delays. However, it would be possible to make them user-configurable in the J-Link software, so that also slower VPN connections are possible. You could also try our J-Link Remote Server in tunneling mode with one of your USB-based J-Links. The tunneling mode was introduced exactly for this case, debugging remotely over internet, expecting big latency: segger.com/jlink-re…

  • Hi, Quote: “ I believe, the "Erase chip" command from J-Link puts 0x00 instead of 0xFF at address 0x400. Hence, J-Link does write in this region!” Does not make sense... If you do a chip erase, all bytes in the internal flash will be set to 0xFF. Please note that the readout protection at 0x40C is defined as: 0xFF == device is read protected. This is a specification that comes from the Kinetis device. However, J-Link is able to recover a device that has all bytes (including the readout protectio…

  • O.K. ... From what I have seen, GDBServer never crashed but it was always GDB that closed the connection (maybe due to crashing). As both are independent processes, it cannot be a problem in GDBServer (which is the SEGGER component) My guess: There was some internal problem in DAVE that caused GDB to crash when evaluating a specific part of debug information in the ELF file etc. However, it is just a guess. Let's close this case for now. - Alex

  • Alright, good to hear that you are up and running again. Thanks for letting us know. Case closed.