Search Results

Search results 1-20 of 1,000. There are more results available, please enhance your search parameters.

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

  • The xc command is probably not the correct way. GDB Server is basically a translator from GDB to J-Link and takes care of the flash programming on certain memory writes. ELF file loading etc. are all more GDB things. Maybe this is of any help: dzone.com/articles/multiple-binaries-with-gdbeclipse Unfortunately, I cannot provide any CLiom example but most steps should apply to any GDB based IDE, so you may be able to adapt the steps for CLion.

  • EraseSector() must only return when the erase of the sector is complete. The timeout is a value that must not exceeded by an EraseSector() call.

  • How much current does your board draw? Did you make sure that it is within the specs of J-Link? Did you make sure that you have connected J-Link to a USB hub that has its own power supply? If not: Did you make sure that J-Link is the only device connected to the hub? Do you use the power on perm feature of J-Link or do you switch on the power automatically at debug session start?

  • Hi, Can you please provide the full Python code, command files etc. you are using to get RTT data from JLink.exe? If this is an issue on our side, we need some more information about the exact setup and what exactly should happen, according to the code.

  • What device (manufacturer and device name) are you using?

  • Can you please describe what exactly you are doing? - Starting nrfjprog.exe to program the device - Exit nrfjprog.exe - Starting jlink.exe to do what? How do you get the RTT data? Do you connect directly via TCP/IP to a specific port? Do you instruct jlink.exe to start RTT etc.? If yes, what exact commands do you pass to jlink.exe? The easiest would probably to get your Python script to get an idea what you are doing. Right now, it is not really clear what is involved and what steps *exactly* ar…

  • Hello, We are currently investigating an issue with TMS570LS devices and the latest CCS plugin. It is not related to the "The selected device xxx is unknown to this version of the J-Link software" dialog you are getting but may cause debugging to not work. I recommend to wait for the new version that fixes the issue we are currently investigating and take it from there. BR Alex

  • Only one process can listen on a port. If you start nrfjprog.exe first, it gets the 19020 port, so it will be the default instance RTT Logger connects to. You either need to add a delay between exiting nrfjprog.exe and starting JLink.exe (otherwise you have a race condition if JLink.exe gets the port or not) oooooooooooor simply do the download from JLink.exe as well (which will be faster anyhow...) Neither the post you referenced, nor the issue in this thread are J-Link problems. J-Link does no…

  • Thanks for confirming that it was an issue in your setup. Pulling the plug in the middle of the work is like getting your hands of the steering wheel of your cars when driving on a crowded highway and a high speed. There is a pretty high chance that you will be in an accident. (You don't have to but there is a pretty high chance) Script mode of J-Link Commander is not different from interactive mode where you type in commands. Issue Ctrl + C in interactive mode and J-Link Commander will also not…

  • Hello, I understood it that way but thanks for summarizing to avoid misunderstandings. This does not change the fact that pic1 shows "V6.44b" in the message box title and not "V6.88". Do you agree? So the fact that the message box shows a version != V6.88 indicates that your CCS installation is *not* using a V6.88 version of the J-Link software. Moreover, since you are using V6.44b in CCS (according to the screenshot in pic1) the error message makes sense because if you look up the release notes…

  • While we cannot comment on the compatibility to the board, the MCU should not be an issue. As you stated in the other thread, you can connect to the MCU via J-Link Commander (JLinkExe), it is proven that the EDU Mini is fine. If VsCode does not work, it‘s an issue in your setup. However, Fabian already provided some links etc. with VsCode startup help but in the end this is more a question for the VsCode community. We will close this thread.

  • Currently, only [mA] is available and there are currently no plans to support anything else than probably [uA]. Accumulated power consumption: Currently not, but we will put it onto the agenda for the next meeting

  • Actually, I do not see why there is any RAMCode needed at all. It should be a few memory writes followed by a read, to get the UID. We can offer to write such a script as a service if you would like.

  • Something reg. your statements cannot be correct. As can be clearly seen in the screenshots, the message box from CCS shown J-Link V6.44b and not V6.88 like the Commander etc. Without having checked the release notes I would say that the TMS570LS20216 has been added/implemented in a later version... You should check your setup. CCS is definitely NOT using V6.88 / V6.88a

  • Of course it will not work if you select „Cortex-M0“.... This is why we offer different device selections because every device has a different flash algorithm. Cortex-M0 does not tell J-Link ANYTHING about how flash programming for a particular device works. Did you actually check the links I provided for what the correct device name for you is?

  • Actually, it more sounds like you either had a bad/incomplete bin file or flashed it to the wrong address, so J-Link is probably the wrong thing to blame here. J-Flash Lite uses EXACTLY the same flash programming logic as JLink.exe does.

  • Did you make sure that RTT in Ozone is disabled? Otherwise, Ozone may get the data, show it in its own windows and there may be nothing left for RTTViewer to show...

  • The out of sync message is related to USB. The USB protocol is out of sync. Meaning, the PC may have sent a half command to J-Link, so it is still waiting for the rest of the command etc. Or the PC did not get the whole answer to a command out of the host buffer so the new session gets it and does not know what to do with it. USB is a commectionless protocol, meaning that J-Link has no chance of detecting that a USB handle on the host may have been closed due to process dying or abnormal termina…

  • Hi, At least on the photo, you have NOT connected the battery to pin 1. Pin 1 is indicated by the BLUE wire on the cable. Maybe that‘s also the problem on your custom board wiring: Wrong direction of the debug connector... BR Alex

  • Can you please post the log output you get? It obviously must be different from the first log you provided in the beginning of the thread.