Search Results
Search results 1-20 of 982.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Hi, Quote from tinydrop: “I connect target device with swd (7pin 9pin 2pin) ” It should be: 7 - SWDIO 9 - SWCLK 1 - VTREF (not 2) 5 - J-Link-Tx (J-Link out => Target in) 17 - J-Link-Rx (J-Link in => Target out) One of the pins you mention is wrong. If this does not fix the issue: Could you please check the following? wiki.segger.com/Using_J-Link_V…M_functionality_and_speed If the self test works, the issue lies on either - the connection between Target & J-Link (Faulty cables, Wrong pins connect…
-
Hi Peter, We are not aware of any such issue. I just gave it a quick try and it works without issues on my side, using an STM32F407VE: Source Code (2 lines)Resulted in the lines: Some 123 Test 456. Some 456 Test 123. Could you please provide a working sample showing the issue? Which MCU are you working with? Are you using the RTT source code from the latest release? segger.com/downloads/jlink#J-L…twareAndDocumentationPack Best regards, Fabian
-
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, 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, 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 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 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…