Search Results

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

Hi Jonathan, As you also contacted us per e-mail, we will follow-up on the e-mail channel. BR Alex

to 1) No to 2) The conversion utility only supports ST-LINK V2 on-board. Neither stand-alone ST-LINKs nor ST-LINK V3 in general. Edit: Note that the STM32WLE5x can operate from 1.8V to 3.6V while the EDU Mini only supports 3.3V targets. Just in case you are not using that MCU in 3.3V mode

Where do you see an error there? I do not see any “error” introducer to that message, so it is more an info message. If such an output on stdout breaks your scripts, your scripts are broken by design. There is no guarantee that J-Flash stays 100% silent on stdout. You should also not parse any stdout for errors. The return / exit value of J-Flash is what matters.

You probably misunderstood me. I am NOT talking about multiple JTAG interfaces. I am talking about exposing 1 JTAG interface (so 4 pins) or even better only 1 SWD interface (so 2 pins). All cores would be accessible via the same DAP, just different APs. It is a very common implementation in the ARM world and can be mixed with RISC-V as well. For example, many of the bigger NXP i.MX devices have multiple M-cores, some A-cores and even some Xtensa cores in them and all is accessible by a single 2-…

I do not see why it should not be possible. Having GDB Server to do the semihosting operation means that everything is relative to the machine GDB Server is running on. Using semihosting I/O client mode 2 will have all semihosting operations being done by GDB, so everything happens on the machine GDB is running on. wiki.segger.com/J-Link_GDB_Server#semihosting_IOClient

Hi, Assuming that all of the cores are part of one chip / SoC, the best would be to have 1) the RISC-V ones behind an APB-AP 2) the A35 ones behind another APB-AP 3) The M4 ones behind one AHB-AP each This would allow a JTAG independent design (would also work with SWD or cJTAG), while chaining would limit you to JTAG and make things slower because each TAP adds overhead to the total length of a single JTAG access.

I am confused… First, you posted some output in which you get a syntax error for „loadfile“. Then you posted some output with an almost identical call to „loadfile“ but there is no syntax error. Instead, the flash programming is started and reports that the contents of flash already match the contents from the file, so no programming is necessary. But at the same time you write that things do not work… We need more details here. What fixed the syntax error from the 1st round? What contents do yo…