Hi,
We noticed that you opened the same inquiry via our ticket system.
We have already responded to you there and will close this thread.
Could you please refrain from opening the same inquiry on multiple channels?
Otherwise, there may be additional workload on our end.
In addition to that, it could lead to loss of information across the channels.
Thanks!
Hi,
we received you inquiry via our ticket system and responded there already.
Please refrain from contacting us via multiple channels in parallel - it causes additional workload on our end.
Additionally, one of the channels may end up with less information than the other.
J-Link Remote Server's error message "Failed to put socket into listening state." indicates that
another process on your machine has opened a listener socket on the same port that J-Link Remote Server tries to open.
This may be another instance of J-Link Remote Server started before,
or any other process that decides to listen on port 19020.
In your case, "a windows svhost process" was blocking port 19020.
https://wiki.segger.com/J-Link_Remote_Server#Troubleshooting
BR
Leon
Hi,
Alex asked me to investigate the behavior you reported.
I gave this a quick try using the most recent version of J-Mem (V7.88d) and everything worked as expected.
The memory from 0x0000_0000 to 0x0001_0000 was filled with 0x5F, even the range outside of the area visible in the J-Mem window.
Could you please download and install the most recent version of the J-Link software package and give J-Mem a try again?
Does it work as expected for you now?
https://www.segger.com/downloads/jlin…cumentationPack
BR
Leon
In addition to Alex' comment:
lj001:
The output of "JLink.exe" that you sent is not from J-Link Commander nor any software developed, provided or maintained by SEGGER.
It appears that the JLink.exe that you are calling is a different application, developed by a third party.
You can determine the full path of the executable using
"where JLink.exe" on Windows.
One possible source for this issue could be an installation of the "AdoptOpenJDK" by adoptium,
which comes with an executable called "jlink.exe" despite no relation to J-Link at all.
We recommend you to install the most recent version of the J-Link software package
(https://www.segger.com/downloads/jlin…cumentationPack)
and start J-Link.exe using the path to the J-Link installation instead of just "JLink.exe".
Please understand that this issue in particular is not caused by any SEGGER software.
Hi,
Such an issue is not known to us.
I just checked and the J-Link RTT Viewer V7.82 works as expected for me.
This, in addition to the fact that this is the only report of its kind (at the moment) indicates that the culprit of the behavior you are describing is inside your specific setup, rather than the J-Link software.
Did you make sure that your desired target application was downloaded to your target?
Did you change anything else, besides the RTT Viewer version
(e.g. connectors, cables, PCs, target device, target application, ...)?
Could you please provide some additional information on your setup?
BR
Leon
Hi,
We will close this thread as you submitted the very same request via our ticket system already
and further communication will be handled there.
Please refrain from sending us the same inquiry via multiple channels.
BR
Leon
Hi,
J-Mem can already save memory data to a file (see screenshots below).
Please note that as of right now, only the .bin format is supported.
We will add "support for other file formats like .hex, .srec, ..." to our internal list of feature requests for J-Mem
BR
Hi,
We can reproduce this issue and will work on a fix for this ASAP.
Thanks for bringing this to our attention!
Hi,
Hi,
Good to hear that you are up and running again.
I will forward your suggestion internally.
Hi,
Correct, .pex files can only be created by SEGGER.
We may be able to help you here, if you could provide some more information on your J-Link script file.
What exactly are you trying to achieve and what does not work as you expect?
Hi,
As you have submitted this inquiry via the ticket system too, we will close this thread here.
Please refrain from submitting the same inquiry via multiple channels, as this will just slow things down.
Follow-up:
1) Enable/ Disable auto-scroll
This feature is already implemented.
Could you please download the most recent release of the J-Link RTT VIewer and check?
https://www.segger.com/downloads/jlin…cumentationPack
In the menu bar under "Terminals" there is a menu action "Autoscroll on new output" which can be enabled/ disabled accordingly.
Hello,
Thanks for you suggestions!
1) Enable/ Disable auto-scroll
I agree, such a feature makes sense.
I will put it on our internal ToDo.
Please note that we cannot provide an ETA for this as we are fully booked and
we have no plans of "outsourcing" work of this kind.
2) Keyword search
I can see how such a feature can be an improvement,
but we will have to check the efforts necessary to implement such a feature.
I will add this suggestion to our internal RTTViewer wish list.
3) Message timestamps
Unfortunately, this is not as straight-forward as it may seem.
RTT Viewer itself has no way of knowing when a message was "printed" by the target.
RTT data is buffered in multiple places along its way to the RTT Viewer (target application, inside J-Link, inside J-Link DLL, ...),
so RTT Viewer cannot tell at which time a message was "printed" by the target application.
The application also has no way of knowing how much time passed between two "printed" messages, either.
So the only way to have reliable (e.g. useful) timestamps for RTT messages is to implement them on target-side,
which is user responsibility.
Hello,
Thank you for your inquiry.
We have fixed this behavior internally already.
A new version of the J-Link software package which contains this fix is planned to be released next week.
Stay up-to-date regarding J-Link:
Hi,
Thanks for your inquiry.
Dialog buttons:
I understand your concern and we are already aware of this.
Please understand that the button position (and other GUI layout) is the way it is due to historical reasons.
In the past, the J-Link software package was only available for Windows, which is why the "Cancel" button is to the right of the "OK" button.
We try to keep the GUI of the J-Link software as similar as possible, regardless of platform.
That way our customers can switch between Windows, macOS and Linux without having to readjust to a different layout or similar.
Due to that, it is possible (and sometimes intended) that some J-Link software GUI layout may not match cosmetic guidelines of the platform it runs on.
Application icon:
Thank you for bringing this to our attention.
I will mention this in our upcoming team meeting.
Misaligned text in buttons and dropdown menus:
Thank you for bringing this to our attention.
We will check how we can improve this behavior.
Menu ordering:
Thank you for bringing this to our attention.
We will check how we can improve this behavior.
Qt warnings:
Thank you for bringing this to our attention.
We will check how we can improve this behavior.
J-Link commander comments:
Thank you for bringing this to our attention.
I will mention this in our upcoming team meeting.
Please understand that I cannot assign a high priority to the requests that you made,
as they are "cosmetic" and do not restrict the usability of the J-Link software.
Hello,
we have determined the root cause of the unexpected behavior that you described.
The issue has been fixed internally already.
The fix will be part of the next version of the J-Link software package, planned to be released later today.
Sorry for any inconveniences caused by this.
Thank you for bringing this to our attention.
Hello,
Thank you for your report.
I was able to reproduce the issue that you described.
We are working on a fix for this right now.
I will get back to you ASAP.
Hello,
Thanks for your reply.
I am not sure if I understood your procedure correctly, but it sounded like you are checking the J-Flash log file to check if the programming has succeeded or not.
We recommend to check the return value of J-Flash for that.
More information as well as a sample batch script can be found on the SEGGER Wiki:
https://wiki.segger.com/UM08003_JFlash#Command_line_options
https://wiki.segger.com/UM08003_JFlash#Batch_processing
Could you maybe provide some more information on your setup?
Could you try and execute the "Slave" programming step only, without doing the "Main" programming step, in order to isolate the issue further?
Does the issue with your "Main + Slave" steps occur when executing J-Flash from a batch file, without using LabView, too?
Please note that this is the only issue of its kind that has been reported so far, which is why we assume this issue to be setup related.
Hello,
we have successfully determined the root cause for this.
With the version V6.82 of J-Flash, a bug was introduced unintentionally,
causing the command line options "-savedat" and -"-savecfg" to no longer work correctly.
We have fixed the behavior of J-Flash internally already.
Thank you very much for reporting this issue.
A version which contains the fix is planned to be released later this week.
Sorry for any inconveniences caused by this.
