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.

  • Sounds strange... Is it possible that the USB hub, the J-Links are connected to, is not powered externally or its external power supply is broken? This would cause the hub and all J-Links connected to it to be fed from the USB cable that goes to your PC. Maybe it is just too much for that port and it cannot deliver sufficient current, so USB works unstable then? I still not see why it should affect your screen in any way but it would explain the "ding" which indicates USB detach + reattach/re-en…

  • Agree or not, your choice. Fact is: All J-Link flash loaders are designed to work with the natively memory-mapped space of the chip. For the RP2040 this is 16 MB, according to the datasheet. This means, J-Link will be able to program & verify 16 MB of QSPI reliably. Moving the 16 MB “window” to another portion of the flash (so effectively configure the QSPI controller to use fixed high-bits != 0 during memory mapped accesses) is not supported and there is no plan to do so. (Even though it would …

  • Hi, If the memory-mapped region supports max. 16 MB, this is what your flash loader does support as well. All our flash loaders support max. what is mapped in the address space of the MCU. So what you describe is not a bug and no, we have not “misinterpreted” the datasheet. If flashing beyond 16 MB on this MCU somewhat / half-way works, consider yourself lucky but don’t rely on it. If you want to have support for space beyond that (which is not XIP and therefore not “directly” debuggable anyhow)…

  • While RTT Stop-Mode in general might be working for the J-Link you use, stop-mode support on the RM48 may require further features that are specifically needed for RTT on RM48 in general, but these are not provided by the J-Link in use. In general, the J-Link you use is a V8 model which is pretty likely 10+ years old and has been out of support and maintenance, so there is no support, bugfixing or even analysis done on it. If the same issue comes up with a current model, we recommend to open an …

  • Not sure what you mean with “There must be a simpler way”. What do you have in mind? Can you describe the “simpler” setup you have in mind? As RTT goes through the debug interface, you need an active debug session that does all the RTT handling and you can attach to via TELNET.

  • How about this? mem32 0x21BC460, 1 wiki.segger.com/J-Link_Commander#Mem32

  • Hi, Does the latest version still show these effects? V7.90 is from August 2023 (while we are currently in Feb 2024) and there have been several updates since then. segger.com/downloads/jlink/ BR Alex

  • Even more unfortunate that you did not mention the exact device in use in the first place and that you were missing support, but instead let us guess and invest time into an answer that you already knew / probably expected... However, I invested some more time and checked for a quick solution: You should be able to use the PIC32MX130F128H by selecting "PIC32MX150F128B". From the debug & flash programming point of view, they should be compatible. Can you please give this a try and provide some fe…

  • RTT timing

    SEGGER - Alex - - J-Link/Flasher related

    Post

    As the bottleneck is mainly the debug interface, USB3 probably gives a bit of better performance over USB2 in this discipline but if it is significant or even crucial, is something only you know. I do not have any USB2 vs. USB3 RTT comparisons at hand. I still don’t know what exactly you are trying to do (don’t get it fully from your initial post)

  • Hi, Well, you need to pass the correct name to J-Link… Not all devices share the same algorithm and flash size, so J-Link needs to know which device it is talking to, in order to have the correct algorithm selected. List of valid device names for PIC32MX family: segger.com/supported-devices/search/pic32mx BR Alex

  • RTT timing

    SEGGER - Alex - - J-Link/Flasher related

    Post

    The statement you quoted refers to the tome needed on the MCU side to get that line into the RTT buffer. This is “the important time” because it is basically the time that your application is blocked from doing its normal work. When the buffer is actually emptied / read by J-Link, is not really of interest, as long as the buffer does not run full, which would cause data loss or delaying the application work. BR Alex

  • RTT timing

    SEGGER - Alex - - J-Link/Flasher related

    Post

    As the SDK is not free of charge / open, I recommend to use the official support channel for it. (See signature below my post) Otherwise, your posts may get hidden / deleted. BR Alex

  • OK, so this is unrelated to the Linux issue we fixed with V7.94e. We will check if we can reproduce things.

  • RTT timing

    SEGGER - Alex - - J-Link/Flasher related

    Post

    RTT has no guaranteed timing. J-Link polls the RTT control block on the target for new data, as fast as possible and whenever there is data, it is read. The point is to get data out of the target as fast as possible, so buffers on the target can be kept small. Not sure what exactly you are asking for and what the point is of reading the samples one by one. It is just against the concept of RTT…

  • Hi, There is no probing / trying (and has never been) for the correct pin config for exactly the reason you mentioned. J-Link detects the connected flash by reading its ID via the RDID command but there is always a fixed pinout used. Can you please send some screenshots that show your actual J-Flash settings that you see this issue with? Device selection, loader selection, enabled flash banks, … Alternatively, you can post your *.jflash file. BR Alex

  • Do you mean V7.94d or really V7.49d? If it is V7.94d: Do you also see the issue with V7.94e? There was a hotfix for Linux in that version but in case it fixes a problem on your machine as well, we will have a look again what happened for macOS because there is no known isssue under macOS.

  • Hi, There was a V7.94e with a hotfix for Linux. Pretty sure that you ran into that issue. segger.com/downloads/jlink/#J-…twareAndDocumentationPack BR Alex

  • Hi, A J-Link script file is the wrong approach here. GDB Server has zero knowledge about the ELF file. All the debug information parsing (function/variable names, stack frames, ...) is done by GDB which has access to the ELF file. GDB only provides the extracted binary application data to GDB Server for the download into the target device. This means, the settings of PC & SP based on the ELF info is something, you would have to do on the VSCode / GDB side, rather than on the J-Link / GDB Server …

  • As far as I understand, it should be possible. Make sure this is part of your FPGA config: github.com/SpinalHDL/VexRiscv#debugplugin and afterwards, the core should be available via JTAG. By using J-Link Commander, following this sequence: wiki.segger.com/J-Link_cannot_…ty_using_J-Link_Commander (use “RV32” as device name, JTAG as target interface and 1000 kHz as TIF speed) You should be able to verify a successful connect.

  • Hi, No logic inside the J-Link software interprets rhe RTT data. It is just forwarded from one side to the other (host -> target or the other way around). All the interpretation of the data itself is up to the host and target application. We will check again but there should not be any problem with sending 0xFF, 0xFE, … down to 0x00 for a byte.