Search Results

Search results 1-20 of 980.

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

  • Hi Torsten, this depends on how you reset the device and what exactly happens when you do so. From the description I would guess that the debug interface is reset, so a reconnect is required to establish it again. As an active debug interface is a mandatory requirement for RTT to work, it would explain the observed behavior. BR Fabian

  • Hi Kaushalya, It sounds like you are using Nordic Tools for handling RTT on PC side, correct? If so, please understand that we cannot provide help for applications which are not supported by SEGGER. If not: Which application are you using? Could you please describe your setup in more detail? Quote from kaushalyas: “I know if I try the serial console, I get a reply for the same command. ” What kind of serial console are you referring to? BR Fabian

  • Hi, We added option byte programming via .hex-file to our feature request list. We will try to squeeze this in within the next couple of weeks. Stay up-to-date regarding J-Link: segger.com/notification/subscribe.php?prodid=7,94 BR Fabian

  • Hi, Both at once: Executed via cross trigger. Not supported yet. It's on our list but without a fixed schedule at the moment. M7 only: You should be able to halt the M7 in the M7 debug session. If this does not work, could you please share a J-Link log file of this session with us? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File BR Fabian

  • Hi, You can look them up in the release notes. You can search for the term: "RISC-V: Firmware module version" for differences and compare them. segger.com/downloads/jlink/ReleaseNotes_JLink.html Please note that the list will grow further with time, as features are constantly added and issues constantly resolved. Best regards, Fabian

  • Hi, Currently, option byte programming via .hex file is not supported for the STM32C0 device with J-Link. I will check internally if there are any plans regarding this. Best regards, Fabian

  • Hi, Sorry for the delay in response. We are not aware of any such issue. Are you using the latest version of the software? segger.com/downloads/jlink#J-L…twareAndDocumentationPack If so: Could you please provide a sample data file (e.g. .hex) this issue is reproducible with on an evaluation board? This way we can look into this on our side. Best regards, Fabian

  • Hi, sorry for the delay in response. 0x0800_0000 and 0x0C00_0000 describe the same physical flash area. The first is cached the latter is uncached. When programming data to 0x0800_0000, it is remapped internally to 0x0C00_0000 by J-Link, which was always the case for these devices. It seems that the auto-update did not fully work. If you setup a new project it should still work with the same address range, however, programming to 0x0C00_0000 should lead to the same result. BR Fabian

  • Hi, sorry for the delay in response. Even though it is probably not required anymore, please find the answer below: In general we recommend to make use of our trade-in program in such a case: segger.com/purchase/trade-in-program/ The damaged part is an ESD-Protection. You could try to unsolder the part and check if the OB still works, as it also works without the part. If so, you can replace the part with a new IC (On Semi NUP4114UCW1T2G). If it does not, more parts were damaged by the over curr…

  • Hi, Even though the thread is quite old, an answer to the question can be found here: wiki.segger.com/S32Kxxx#Readout_protection_of_internal_flash BR Fabian

  • Hi, We updated the wiki-page. The "Force go on connect" option is now explained: wiki.segger.com/J-Link_RTT_Viewer#Force_Go_on_Connect Does this answer your question? BR Fabian

  • Hi tsche, Unfortunately, we had to postpone the implementation of PIC32MK support.It is still on our list of feature requests, but without definitive timeline. MIPS is not our core business, so we cannot prioritize this, unfortunately. Best regards, Fabian

  • Hi Peter, No worries! Best regards Fabian

  • Hi Peter, Quote from hotbrix: “As far I understand you, there is no way around this. I need the perma connection to stay open in order to be able to connect to the server. ” This is correct. As long as you want to use RTT, you will have to have an active debug connection. Otherwise it is not possible to retrieve the RTT data from the target. However.. Quote from hotbrix: “So during target programming I have to parallel connections, during unit testing with the telnet client I use only the perma-…

  • Hi tsche, Could you please send us a picture of the front and the back of you J-Link for support purposes? BR Fabian

  • Hi Peter, it seems like you misinterpreted what "SetCompareMode=0" does. This is not really a surprise as it was not properly documented. We will revisit the documentation an adjust this. In short: When SetCompareMode=0 is selected, the J-Link will skip the Blank check and thus has to assume that the device must always be erased before program. => Forcing SetCompareMode=0 will force J-Link to always trigger erase when calling LoadFile. From what I understand you intend to skip the verify, correc…

  • Hi, A good way to approach such an issue is usually the following troubleshooting guide: wiki.segger.com/J-Link_cannot_…the_CPU#Target_connection Additional hints: 1) The STM32F4 devices allow to set permanent protection (RDP level 2), which will effectively disable the debug features of the chip. So if RDP level 2 is set, you will never be able to connect to the chip. 2) In some cases, applications do override the debug pins. In such a case you would also have to connect the nRESET pin between …

  • Hi Peter, First of all: As Alex pointed out, an active debug connection is mandatory for RTT to work. If you are wondering why, please refer to the following article: wiki.segger.com/RTT This does not change regardless of how you retrieve the data (via TELNET channel or via SDK API calls). Quote from hotbrix: “- upload the firmware ” I assume you are referring to programming the target device, correct? From your message it is not clear to me how exactly you are doing this, but I would further as…

  • Hi Pierre, sorry for the delay in response. The issue you described was already fixed with V7.92l: While the update notification pop-up was visible, other dialogs (e.g. flash programming dialog) would not be shown until the pop-up was closed. Fixed. I would suggest to upgrade to the latest version: segger.com/downloads/jlink#J-L…twareAndDocumentationPack To disable the notifications entirely, please refer to the following article: wiki.segger.com/J-Link_Update_Notifications BR Fabian

  • Hi Pierre, The update notification dialog should be non-blocking, so it should not interrupt your script execution. Could you please tell us a little bit more about your setup, so we can investigate this? 1) Which J-Link Software version are you using? 2) Could you please send us a J-Link log file of the session? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File BR Fabian