Search Results

Search results 1-20 of 700.

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

  • Hi Manfred, I am sorry but I think I do not fully understand what the issue is. Quote from mansekurasan: “I want to print to different data streams to different terminal windows. ” I do not see how this would not be possible with a singular buffer. The data is split by the RTT Viewer to the different terminals automatically anyway. Quote from mansekurasan: “The problem is that the refresh rate of the second channel is very fast. What can I do to solve this? ” What exactly do you mean? What chann…

  • Hi, Thank you for your inquiry. There seems to be a common misconception here. I suppose you want to show RTT data on different Terminals correct? However an RTT terminal and RTT channel are two different things. The RTT Viewer only supports terminal output via channel 0: wiki.segger.com/J-Link_RTT_Viewer You would have to use Channel 0 together with SEGGER_RTT_SetTerminal() and/or SEGGER_RTT_TerminalOut() functions to achieve what you want. I would suggest that you revisit the RTT Viewer articl…

  • Hi, Thank you for your inquiry. We would require some more details to help you out here. Could you please send us a screenshot of the error message that is shown? Could you please send us a J-Link log file? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Could you please send us the whole JFlash log output? Could you please tell us which QSPI flash the customer is using now exactly (full name of the component)? Best regards, Fabian

  • Hi, Did you give the file download (without prior reset) on the latest version a try? Is the error message still shown? Regarding the unlock: As you probably know, nrfjprog is a tool developed and maintained by Nordic, so we only have limited information about what it does exactly. However, the device can only be unprotected by issuing a mass erase (as you already mentioned), so I would expect it to work. Could you tell us how often the behavior is showing up? Quote from rookie: “Only way around…

  • Hi, Thank you for your inquiry. You should still be able to connect to the device, as the debug interface should not be disabled, correct? In this case using the J-Link Commander should work: - Connect to the device specifying "Cortex-M4" as device name. - Use the write commands (e.g. w4) to make the S32K148 accessible via verify backdoor access sequence. - Use the write commands to unsecure the device using the unsecure sequence. If you require information about the sequences, please consult th…

  • Hi, Thank you for your inquiry. Did you try to change the USB cable + connect the J-Link directly to a USB port of you PC? If so, it is most likely that your J-Link is no longer functional. Could you please tell us the SN of the damaged J-Link? If you are concerned about sharing it publicly, feel free to send me a direct message with the SN. Best regards, Fabian

  • Hi Johannes, In general: The best option would be to extend your RTT buffer size on target side, so you do not lose data so quickly. Regarding checking VTref: The best option would probably to acquire the J-Link SDK and use it to check VTreff + handle the RTT data: Without the SDK you could probably do the following: 1) Start the J-Link Comander (JLink.exe) with command line options via e.g. Python controlling the I/O. 2) Start the J-Link RTT Viewer and select "Connection to J-Link" > "Existing …

  • Hi, Thank you for your inquiry. I put this on our feature request list. However, we are currently very booked with pressing projects so we cannot provide a fixed timeline for this. If you require this feature sooner / at a fixed date, there would be two options: 1) You could implement the plug-in yourself, with the GDB Server RTOS plugin SDK: segger.com/downloads/jlink/#gdbserver_rtos 2) You could commission SEGGER to implement the plugin. Please note that you would have to pay the NRE in this c…

  • Hi Johannes, there is currently no way to do this with the J-Link RTT Viewer. I will bring this up in our next internal meeting and we will probably put this on the feature request list. Please note that we are currently pretty much booked out with pressing projects. As you are the first customer to request such a feature, we can not give this a high priority. Unfortunately, this means that we cannot provide any fixed timeline. Best regards, Fabian

  • Hi, Thank you for your inquiry. The "Secure Chip" option is deprecated. It is only supported for a hand full of chips for backwards compatibility. There are no plans to add additional chips to be supported by this function. There are two ways how you can achieve what you want. 1) The application itself secures the chip on first boot. This is generally recommended. 2) The chip is secured via the J-Flash exit steps. You can find more information about this topic and some sample projects for STM32 …

  • Hi, Good to hear that the issue has been resolved. We will close this thread now. Best regards, Fabian

  • Hi, Sorry for the delay in response. We added this internally. For future releases, a relative path in a project file will not be detected as a project file change anymore after loading the project. Stay up-to-date regarding J-Link: segger.com/notification/subscribe.php?prodid=7,94 We will close this thread now. Best regards, Fabian

  • Hi, As this case has been resolved, we will close this thread now. Best regards, Fabian

  • Hi, Thank you for your inquiry. This can be achieved via the following steps (in this order): 1) Connecting to the device with the SWO Viewer. 2) Connecting to the device with the J-Link Commander (JLink.exe). 3) Issuing the command "r" (reset) in the J-Link Commander (without quotations). 4) Issuing the command "g" (go) in the (without quotations). Could you please give this sequence a try and tell us if it worked? Best regards, Fabian

  • Hi, Good to hear that you are up and running again. Since the issue is resolved, we will close this thread. Best regards, Fabian

  • Hi Gordon, to keep communication to one channel we will close this thread now. We will answer you via the ticket system. Could you please keep communication to one channel for further inquiries? This leads to unnecessary additional work load on our side otherwise. Best regards, Fabian

  • Hi, I answered this question in my last post. Please follow the link I provided to the model overview: Quote from SEGGER - Fabian: “The max. target interface frequencies supported by the different J-Link models can be found here: segger.com/products/debug-prob…nk/models/model-overview/ ” Best regards, Fabian

  • Hi, Good to hear that the issue does not appear after resetting. However, the error message indicates that there is still something going wrong on J-Link side. Could you please download the latest version of the J-Link Software Pack and try if the issue still persists with it (when not resetting the device)? It is available for download here: segger.com/downloads/jlink#J-L…twareAndDocumentationPack Best regards, Fabian

  • Hi, as you also contacted us via the support ticket system, we will close this thread now. This is to keep the communication to one channel. Best regards, Fabian

  • Hi, Thank you for your inquiry. In general: It is recommended to issue a reset before issuing a flash download. Regarding the message: From your question, it does not seem as if you would experience any errors or issues, correct? If so, is there a specific reason why you do not want this message to be shown? If not so, could you please provide a detailed description of the issue you are observing? Best regards, Fabian