Search Results

Search results 1-20 of 37.

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

  • Hi Fabian, the J-Trace Pro is less than half a year old. If it helps to speed up this use, I will also open a ticket within your support system. The original message, that flashing with the J-Commander works flawless, was not quite correct. I can see problems there two, but much less. My current workaround is, to close the JLinkGDBServer, start the JLinkExe, flash a new version of the software and then start the JLinkGDBServer again. When flashing with the JlinkExe fails, I try some combinations…

  • Is there anything, that I can do to mitigate the problem? Currently, it took me 20 retries to get the flash content to the controller. I don't know if this relates to a OS/X security update I've installed this morning, but for a >2000€ debug probe, the user experience is quite "not sooo good".

  • That would be very helpful. Currently I have to start GDB 3-5 times, and search the tiny font on the GDB server to look for error message. May I propose to maybe print the error message in red, so that error could be spotted easier? Anyway: thanks for taking care of this.

  • While I was searching for similar error messages here in the forum, I found some cases, where the wrong device type caused similar problems (albeit more reproducible). I received the device type with the schematic of the hardware I'm working for. So I got a big magnificent glas and verified, that the actually used type is really a ATSAM4SD32C.

  • As I'm still looking for a solution, I'm poking around a little bit and realized, that the J-Flash Lite software that comes with the J-Trace Pro, also has problems erasing the flash (I dunno, if that is somehow related to my problem): Quote from J-Flash Lite: “Connecting to J-Link... Connecting to target... Erasing... ERROR: Could not erase chip.Done ”

  • Hi Nino, thanks for looking into this. No, it doesn't work (beside the command for reseting seems to be "r" not "reset"). I'm getting reproducible an error while executing the "erase" command: Quote from Error while erasing: “J-Link>erase Erasing device... ****** Error: Failed to erase chip @ address 0x00400000 (Algo47: Sector is locked) Failed to erase chip. Failed to execute RAMCode for chip erase! J-Link: Flash download: Total time needed: 5.174s (Prepare: 0.195s, Compare: 0.000s, Erase: 4.90…

  • Here is a second example: Quote from Segger GDB Server log: “Connected to 127.0.0.1 Reading all registers Read 4 bytes @ address 0x00403DDE (Data = 0x4770BC80) Read 2 bytes @ address 0x00403DDE (Data = 0xBC80) Received monitor command: speed 1000 Target interface speed set to 1000 kHz Received monitor command: flash breakpoints = 0 Flash breakpoints disabled Received monitor command: flash download = 1 Flash download enabled Received monitor command: flash device = ATSAM4SD32C Selecting device: …

  • Hello, I'm using a J-Trace Pro to debug an ATSAM4SD32C. While I've tried to figure out, why my code is not doing, what it is supposed to do, I came to the conclusion, that the content of my elf file is not flashed correctly. This is not 100% reproducible but if I inspect for example the interrupt table and compare it with a list file or hex file, I find the address of the Reset_Handler to be "reasonable", but not correct. In the log of the SEGGER J-Link GDB Server V6.54 (GUI Version), I found a …

  • Hi Niklas, Hi Erik, thank you for your response. Maybe our scripts are missing some details and JlinkExe stopped to guess for that. Looks like that fixing our scripts is a doable job. cheers, Torsten

  • Hello, I just upgraded by JLink software to version V6.10k on OS/X and this broke my build and test environment. We build and execute jlink scripts based on configured build targets. For example, to erase the flash of a device, we generate a file called erase.jlink and use JLinkExe to execute this file. This worked fine, for the last two years, but now with the new version, JLinkExe starts to propt for additional informations: ... Please specify device / core. <Default>: NUC140LE3 Type '?' for s…

  • Hi Nhiklas, yes, you are right, that's the option I was looking for. And now, the option is in my copy of the documentation too. How do you did that? I can swear, the last time I was looking for it, it was not there Thank you! cheers, Torsten

  • Hello, I have two JLinks connected to my OS/X computer. When flashing a device, I want to select the JLink to use. According to 4.6.1 this seems to be possible in general. But now I fail to find the correct command line option to JLinkExe to select the correct JLink. Does the JlinkExe not allow to select the JLink, or is this just missing from the documentation (Document: UM08001 V5.02e)? I saw that it is possible to select an other JLink, once JLinkExe is startet (using the "usb" command), but …

  • Hi Bunny, works like a charm! Thank you very much! cheers, Torsten

  • Hello, I currently try to debug a on a nordic eval board with integrated JLink, while I use a second eval board with integrated JLink as Bluetooth sniffer (boards are different and I can't change there purpose). With the JLinkExe tool, I can use an `usb` switch to tell, which JLink I want to use. Is this possible with JLinkGDBServer too? I can't find something like this in the documentation. OS is OS/X, JLink-Version is V5.02h. When I start the debug server, it always chooses the wrong JLink (ac…

  • I can confirm that this workaround works for V4.94c. Thank you, Torsten

  • PC sampling

    Torsten Robitzki - - J-Link/Flasher related

    Post

    Hi Alex, thanks for replying. Instrumenting code is to much hassle and impacts performance to much. I'm a big fan of statistic pc sampling, because it is usually easy to implement, more accurate and less intrusive. Unfortunately therefor I need a spare timer on the target, or some other mean to sample the pc and the stack. Cheers, Torsten

  • PC sampling

    Torsten Robitzki - - J-Link/Flasher related

    Post

    Hello, I currently think about how I could profile my code. The target is an arm cortex m0 (Nordic nrf51422). I like program counter sampling as a statistical method, because the code doesn't have to be instrumented. Now I wonder, if I could use my Jlink-Debugger to sample the program counter (event at a very low rate) and the call stack (possible with some inconsistencies), without halting the CPU? Does some of you have experience with using the JLink for profiling? cheers, Torsten

  • Hello, I'm currently writing a BLE boot loader for a Nordic ARM ship (nRF51422). I use cmake for my build process, that creates an elf-file, which is converted into a hex-file, which is converted into 2 bin files. One bin file is the content of the hex file, that contains the boot loader binary. The second bin file, is the content of the hex file, that describes one 32-bit value that have to be written to the so called UICR of the chip. The UICR is a flash region that is shorter than the usual p…

  • Hello, when I use Jlinks "savebin" command, to store a flash area, I get a file without any ACL informations: Brainfuck Source Code (8 lines) kind regards, Torsten