Search Results

Hi Alex, well I'm not sure, if I really want to understand the inner details of your RTT implementation. According to the white paper on your website, it is basically polling some memory regions via SWD. So from technical perspective, I can not see, why the viewer / JTrace stops polling when there was an error condition, but of cause I'm not familiar with all the necessary details. Anyway, my task was to replace a debug UART by RTT, which seems to be not possible, because we would always miss th…

Hi Fabian, I reset the device in two situations: - While flashing new firmware, where the reset is then executed by the JTrace - By simply performing a hardware reset (pull nReset to low) In both cases, I have to do the reconnect, which is somehow annoying. I do not power down the JTrace, nor do I disconnect the JTrace. To me, this doesn't look like uncommon use cases Do you think, this could be improved somehow? best regards Torsten Other observation: When I do some logging with a frequency of …

Hello, I have a problem, porting an nRF5340 based Zephyr project from logging to an UART to logging via RTT. I have a J-Trace Pro Cortex-A/R/M connected to a Nordic nRF53. JLink Software Version 7.96c. Maybe someone here has made similar experiences and has an idea as to how to overcome them. Observation: Zephyr is configured to use RTT as logging backend. I have small test program, that just writes some log messages. Logging to JLinkRTTViewer stops as soon, as I reset the device. Once, I discon…

Hi Fabian, I would require both. best regards, Torsten

Hi, currently I have to work with a TMS320F28379D from TI. There seems to be no support from Segger for these kind of chips. Are there plans to support them in future? If not, why not? best regards, Torsten

Hi Fabian, looks like this would have been the solution. Haven't tried to flash the firmware, but the JLinkExe is reporting correctly the CoreSights components of the controller. Thank you very much for further looking into this! best regards, Torsten

Hi Fabian, please find attached a picture from the setup I've used yesterday. I've checked the 3.3V on the connector at the lower left side of the board, I attached the logic analyzer to the TMS and TCK pins on the left connector side. best regards, Torsten

This is a follow up to [SOLVED] LAUNCHXL CC26X2R1 + Code Composer + JLINK EDU MINI unfortunately the thread is closed and I would like to ask the OP how he managed to flash the board, using a JLink. I've removed all jumpers that where not necessary to provide power to the board and connected my J-Trace (using latest SW version V6.72b). JLinkExe just gave similar error messages (trying to reset the board): Source Code (14 lines)I've attached a logic analyzer and at least saw traffic on the SWDIO …

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 …