Search Results

Hi, Yes, unfortunately they are using multi-drop to control access to the cores in the MCU (which does not really make sense and is not what multi-drop was designed for) but it is what it is. We just added basic debug support for it internally today (no official version yet). QSPI flash programming support is work in progress. A first beta version may be available by the end of this week or sometime next week. BR Alex

Did you try the debug build of your project and step through it? Does that work?

Hello, We have added support for the BBC micro:bit V2 (separate firmware image was necessary): segger.com/downloads/jlink/#BBC_microbit Landing page, wiki etc. are all going to be updated during next week. BR Alex

Maybe this helps: wiki.segger.com/UM08001_J-Link…flash_contents_at_runtime

Just because a standard allows it, it does not have to make sense to do it. It makes system bus access only half-way useful and not really a replacement for access via the CPU. So far *all* other implementations we came accross so far have implemented system bus access as a full replacement for access via the CPU. However, in the end you are right, J-Link seems to ignore the initially detected system bus limitation, so it is a mistake on the J-Link side. Will be fixed in one of the next versions…

Hi, No, you are not correct. If you write a open flash loader for this, you can use J-Flash. It is just that we do not have such a loader available out-of-the-box for your setup. BR Alex

Hi, What you are using is a NAND flash. NAND flashes are not memory mapped accessible, so you need a customer flash loader to access them (for read & program). While memory mapped parallel CFI NOR flashes are somewhat standardized reg. their command set and are simply accessed memory mapped through the CPU, for NAND flashes they are usually connected to a NAND flash controller of your MCU which is MCU specific and different for each MCU. We do not have any NAND flash loader available for the OMA…

We used a different memory offset because we did not have your target in house. We also currently do not see why the address of the instruction should have any effect. However, we will check. Can you please let us know what connectors and what pinouts to use to connect J-Link to the ARTY boars, using your bitstream(s) (also the ones from the other thread)

If it was working before, you have probably flashed something into the MCU that inhibits debugger connections. Are you working with an eval board or custom HW? If custom HW: Do you have connected the reset pin of the MCU to J-Link? If not: Can you please connect it and try again? BR Alex

Hello, We investigated and discussed this internally. With the current build setup and adding support for the J-Link GUI applications under Linux ARM also, we had to drop ARMv6. For now, there are no plans to bring it back because ARMv6 based Raspberry Pi setups are quite rare nowadays. BR Alex

Hi, VCOM cannot be used in parallel to JTAG. If you use SWD instead of JTAG, you can use VCOM in parallel. Reg. the big connector: How about this? segger.com/products/debug-prob…rs/10-pin-needle-adapter/

Hi, Thanks for bringing that to our attention. Actually, the software is build on ARMv8-A based systems (Rpi 4). However, it was not intentional to break ARMv6 support for the 32-bit version. We will check that. BR Alex

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…