Search Results

Search results 941-960 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.

  • Hi, Quote: “Never mind. I just put the DLL file in the folder C:\Windows\SysWOW64 and then it works.” Wow, dangerous... Please note that this will have side effects: For example IAR EWARM installations on your system will now *always* use the DLL in this System folder. Whatever version they are shipped with, it will no longer be used. The one in the system directory has precedence. We recommend to *not* put the DLL directly into system folders. Best regards Alex

  • Hi, Good to hear that everything is working now. Best regards Alex

  • Hi Jack, See UM08001 (J-Link User Guide), chapter "Setup" => "Getting started with J-Link and ARM DS-5" DS-5 is not really designed to support debug probes from 3rd parties... Best regards Alex

  • Hi, Wondering why this should happen... Can you provide some more information about your system? Operating system, USB root hub vendor, J-Link model you are using... We would like to check if there is something in the USB stack of the J-Link firmware, we can probably improve here to prevent this hanging state. Best regards Alex

  • Hi, What struggles me: GDB sets a hardware breakpoint with size 4 bytes at 0xC027EB36 (which is a non-4-byte aligned address)... Sounds a bit like the CPU is in Thumb-Mode when entering this code but GDB is not really aware of that and assumes ARM code for whatever reason. Of course it will not work correctly, setting a hardware breakpoint configured for a 4-byte instruction fetch, on a non-4-byte-aligned address. This will cause the CPU to halt, as soon as an instruction is fetched from 0xC027E…

  • Hi Mike, Glad to hear the problem is solved. Normally, we do respond in a timely manner, this has been an exceptional case. But also: It is very hard to analyze what is wrong on your hardware (missing capacitors or too far away from device) by basically just knowing that J-Link is not able to control your device in some cases (basic communication with the device was working perfectly, everything just started to not work correctly when you tried different flash programming related things). Anyhow…

  • Hi, Can you provide a test application (in source if possible) which allows easy reproduction of this issue? - Alex

  • Hello Roy, J-link supports debugging via the standard JTAG interface on the i.MX6. As far as I understand, the secure JTAG (SJTAG) is a special unit in the i.XM6 which, if enabled, needs to be initialized with a security key to enable the TAP for regular JTAG debugging. In general, you can write an application with the J-Link SDK which implements this "authentication" via the SJTAG unit and once this is done, you should be able to perform operations via the regular debug interface via J-Link, un…

  • Hi, Sorry, I mixed up something here... O.K., J-Link Commander is not really designed for what you are trying to do. Usually, J-Link Commander does not abort complete operation etc. in case of an error (like not being able to read memory), so there is no real "return value" for such operations. Moreover, J-Link Commander is not designed for production purposes. I still recommend to build your own application, using the J-Link SDK, for what you are trying to do. - Alex

  • Hi, Usual questions: What device are you using (device, not only the core)? What IDE are you using? What version of the GDBServer are you using? What J-Link are you using (S/N)? - Alex

  • Hi, From the J-Link side there is nothing to do... (except maybe adding MTB support to the simple trace API, so debuggers which use this API can also make use of the pre-analyzed trace data for MTB) All that needs to be done, is being able to configure the MTB buffer base address + size in the IDE and the IDE needs to read out & analyze the MTB contents. All of this can be done via simple memory accesses (which is already possible via J-Link), so it is something that needs to be done on the IDE …

  • Hi, From the J-Link side there is nothing to do... (except maybe adding MTB support to the simple trace API, so debuggers which use this API can also make use of the pre-analyzed trace data for MTB) All that needs to be done, is being able to configure the MTB buffer base address + size in the IDE and the IDE needs to read out & analyze the MTB contents. All of this can be done via simple memory accesses (which is already possible via J-Link), so it is something that needs to be done on the IDE …

  • Hi, Quote: “But the problem is that the Jlink commander does not return any error code” This is not true... Both, J-Link Commander as well as J-Flash, return error codes... Quote: “Or is the SEGGER Arm Flasher not really usefull as production programmer? ” Of course it is... And the TELNET / RS232 interface provides almost everything you need for production... There are commands for selecting a certain image, stored on the Flasher ARM, which shall be used for programming. There are commands for …

  • Fixed in V4.84d: segger.com/jlink-software.html - Alex

  • Hi, The internal error has been corrected in V4.84d: segger.com/jlink-software.html Quote: “I have attached the Logfile again for this session. Is the inability to debug a problem with CoIDE and not J-Link anymore?” From the J-Link side, everything is fine. Quote: “I am still unable to view any source code when the execution stop at the first line.” Definitely *not* a problem on the J-Link side. More something for the CoIDE support team... Best regards Alex

  • Hi, Quote: “ I checked the "... With virtual COM Port" option in the later experiments, but IIRC it didn't in the initial install because I didn't want to install the serial port. Do I need both options even if I don't need the VCP, or is the second checkbox only for the VCP/CDC drivers, and the debugger just needs the first checkbox? ” Yes, you always need the VCOM drivers for J-Links which support VCOM. The problem is that such J-Links enumerate with a different product ID than other ones whic…

  • JTAGLoad - Linux

    SEGGER - Alex - - J-Link/Flasher related

    Post

    Hi, Will be added in one of the next versions. Should not be a major thing to port it to Linux. Best regards Alex

  • Hi, Update from our side: Problem will be fixed in the next J-Link software version which will then accept "x" and "X". Best regards Alex

  • Hm, strange... I am pretty sure that I also tested 250 kBaud, 500 kBaud, 750 kBaud and 1 MBaud explicitly. Do you have any chance to check the UART signals? If yes: Is there no output (J-Link => Target) or some output just with an incorrect frequency? - Alex

  • Hi, Not reproducible here... I also have one test PC with Windows XP 32-bit here and a bunch of VMs, also using XP and I do not see any problems on any of them. Quote: “when I attach a Infineon XMC1100 Demoboard with a J-Link Lite,” I think you are referring to "J-Link-OB" here. J-Link LITE is something different... LITE: Separate probe that comes with an eval board OB: On-board version of J-Link which is (as the name says...) on-board and so *not* a separate probe. When installing the software,…