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.

  • 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.

  • Sorry, no idea so far. Still sounds like a setup issue. Needing to get down to 50 kHz is quite harsh… So there is either a HW defect on the PIOs of the EDU Mini or another HW setup issue. I currently do not see any reason on the software side why 50 kHz should make things working while > 1 MHz is totally not working. Even 4 MHz is a quite decend speed where timing etc. is all relatively uncritical and even longer cables should not be any issue.

  • As indicated before, this message is not an error but more some kind of “debug output” from Qt. Will be “fixed” in a future version but without priority right now, as it is not an error or real bug / regression.

  • Hi, J-Link Commander is designed to be used as a verification tool, to be able to verify that several low-level operations work as expected, independent from an IDE. It is not designed to replace an IDE or be a full-blown debugger with ELF file debug info support, source-level debug or automated testing. While some degree of automation is possible with command files is possible: wiki.segger.com/J-Link_Commander#Batch_processing it heavily depends on your setup, if that suffice your needs. For mo…

  • Hi Hila, While I still recommend the DAP / AP method as it allows scaling and adding a next to unlimited number of cores, I can see that keeping the changes minimal may be a desire. I do not see any problems with either of your proposals. Either chaining all (Cortex-M, A, RISC-V) in 1 chain or having the M cores in a separate one. Both should be fine. BR Alex