[ABANDONED] Error just like Thread 4123 but now unknown EMU Command 26

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] Error just like Thread 4123 but now unknown EMU Command 26

    I am seeing an issue with JLink Remote server that looks identical to the "Unknown EMU Command 24" error ([SOLVED] J-Link Remote Warning "Unknown EMU command #24.."), except that it now comes up "Unknown EMU Command 26".
    I saw this error on JLink V618 (Compiled Aug 3, 2017). When I step back to V6.12a, the initial connection is made, but I eventually get an "IP Communications Error" on the client side, and the status goes from connected to disconnected on the server side.
    I could just keep trying different versions, but that would consume a lot of time without any way of knowing if it is worth the effort.
  • RE: Error just like Thread 4123 but now unknown EMU Command 26

    apluscw wrote:

    I am seeing an issue with JLink Remote server that looks identical to the "Unknown EMU Command 24" error ([SOLVED] J-Link Remote Warning "Unknown EMU command #24.."), except that it now comes up "Unknown EMU Command 26".
    I saw this error on JLink V618 (Compiled Aug 3, 2017). When I step back to V6.12a, the initial connection is made, but I eventually get an "IP Communications Error" on the client side, and the status goes from connected to disconnected on the server side.
    I could just keep trying different versions, but that would consume a lot of time without any way of knowing if it is worth the effort.
    A quick follow up. I have V6.18 running on the Client Side but V6.18d on the Server Side. I just tried using V6.18d on the Client Side as well and ran into the same "unknown command" problem.

    I don't know if this is helpful info, but just in case: I did notice that if I connect the V6.18d Client to the V6.18d Server without actually connecting to the target, it initially connects just fine. Once I try to connect to the target I get the "unknown command" error at that point. If I don't attempt to connect to the target, then eventually the server indicates the Client disconnected, while I do not get a pop-up error on the Client side. If I connect the V6.18 Client to the V6.18d Server without connecting to the target, it connects initially, but eventually gets an "IP communication error. Connections closed !" pop-up message error. (And yes, there is a space between "closed" and "!". I mention that in case someone wants to do a string search.)
  • RE: RE: Error just like Thread 4123 but now unknown EMU Command 26

    One more quick bit of additional information: The server is running Windows XP, so I tried a different computer running Windows 7, and used the command line version of the remote JLink server and got identical results. No surprise there, but thought I should try it. :(
  • RE: RE: RE: Error just like Thread 4123 but now unknown EMU Command 26

    So I thought of one more thing to try. I tried the tunnel approach. Get the "unknown command with V6.18d". Using V6.12a on both client and server, I was able to connect the client to the server. However, when I open Tera Term to read the RTT port I open on the Client side, the remote target resets and Windows re-enumerates it. I do see the standard text from the Segger debugger, but none of the target's RTT serial data.

    My ultimate goal is to establish an RTT session with the remote device. :thumbup:
  • Hello Tharon,

    Thank you for the detailed report.
    Such an issue is not known to us.
    We will try to reproduce it and come back to you.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Nino wrote:

    Hello Tharon,

    Thank you for the detailed report.
    Such an issue is not known to us.
    We will try to reproduce it and come back to you.

    Best regards,
    Nino
    Thank you for looking into it. Fortunately, I am not in a hurry on this one, but will need this functionality eventually.

    Let me know if I need to provide any further information. I will share the hardware setup privately if you reach out to me.
  • Hello Tharon,

    Unfortunately i was not able to reproduce the issue on my Win7 machine and a J-Link Pro.
    I will need some additional information about your setup.

    How do you start the JLinkRemoveServer?
    With what application are you connecting to the remote server?
    What J-Link device are you using?
    What target device are you trying to debug?
    Is the issue only showing up with that particular target device or with any target device?
    Does it make a difference with firewall off and on?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • >How do you start the JLinkRemoveServer?

    JLinkRemoteServer.exe


    >With what application are you connecting to the remote server?


    JLink.exe -ip 192.168.0.44



    >What J-Link device are you using?

    nRF52 DK


    >What target device are you trying to debug?

    nRF52832 (nRF52 DK SoC)


    >Is the issue only showing up with that particular target device or with any target device?

    I have tried against two different nRF52 DK devices on two different computers. I have no other targets that are of use to me in my testing.


    >Does it make a difference with firewall off and on?

    The firewall CAN interfere with the connection. I have adjusted the firewall to prevent the issue, though it persists with the firewalls off on both computers as well.

    ??? QUESTION - JLink is usually pretty good about updating the debugger and the driver. I am not 100% certain what version of the device driver and the debugger firmware each of the computers and devices are on. I can't keep changing them out, but if there is one version of the JLink software suite that works, I can update all the device and computers accordingly and just run with that version.

    Thanks!
  • Hello Tharon,

    Thank you for the additional information.
    With it i was able to reproduce the "unknown EMU Command 26" issue.
    We will now investigate further and it should be fixed with the next release version.

    About the connection issues you are seeing they probably come from you using a local IP address for connection.
    Depending on your local network settings this address can change between launches.
    To be 100% certain you can use the approach by selecting the J-Link by Serial number.
    So instead of calling : JLink.exe -ip 192.168.0.44
    Use: JLink.exe IP tunnel:<Serial Number>
    Make sure you use the remote server in tunnel mode for this.
    It is described in detail here.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Nino wrote:

    Hello Tharon,

    Thank you for the additional information.
    With it i was able to reproduce the "unknown EMU Command 26" issue.
    We will now investigate further and it should be fixed with the next release version.

    About the connection issues you are seeing they probably come from you using a local IP address for connection.
    Depending on your local network settings this address can change between launches.
    To be 100% certain you can use the approach by selecting the J-Link by Serial number.
    So instead of calling : JLink.exe -ip 192.168.0.44
    Use: JLink.exe IP tunnel:
    Make sure you use the remote server in tunnel mode for this.
    It is described in detail here.

    Best regards,
    Nino


    I am certain the IP address did not change, though that is always something to keep in mind.

    I need to use the RTT to do something that is not far removed from real time. Nothing hard real time, but would need message responses within a fraction of a second. Can the tunnel handle those kinds of speed requirements? I believe the data would need to leave the US where I am at, travel to your server in Germany, then return to me here in the US. I realize data travels around the world all the time, but not always without some delay.

    I am looking forward to a resolution to the issue.

    Regards!
  • Hello Tharon,

    RTT over such big distances is not recommended and "might" only work.
    Depending on your RTT settings it can either happen, that the J-Link RTT buffer waits on full so new data from the target to J-Link could be lost
    or the other scenario you do not wait on full, now you have the newest data but the oldest might not yet been pushed out by the PC so you might loose them.
    So no guarantees that it will work.

    About the "Unknown EMU Command 26" issue. We found the source of the problem and are now working on a fix.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Nino wrote:

    Hello Tharon,

    RTT over such big distances is not recommended and "might" only work.
    Depending on your RTT settings it can either happen, that the J-Link RTT buffer waits on full so new data from the target to J-Link could be lost
    or the other scenario you do not wait on full, now you have the newest data but the oldest might not yet been pushed out by the PC so you might loose them.
    So no guarantees that it will work.

    About the "Unknown EMU Command 26" issue. We found the source of the problem and are now working on a fix.

    Best regards,
    Nino
    Nino, will you post something here when a fix is available or do I need to scan the Release Notes in the latest releases? I am periodically asked about status.
  • Hello Tharon,

    Yes i will inform you in this thread.
    We know where the issue is coming from but we had to finish other paid projects first before addressing this.
    Currently we are planing to include the fix in the next release version scheduled for the end of the week.
    Should we have something finished earlier we could provide you with a preliminary fixed version if you would be interested into this.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Tharon,

    The fix is applied and it will be available with today's release version.
    Sorry for any inconveniences caused.

    Would you like to be added to the J-Link software update notification list,
    so you get informed automatically when the new version becomes available?
    Subscribe: segger.com/notification/subscribe.php?prodid=7,94

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Nino wrote:

    Hello Tharon,

    The fix is applied and it will be available with today's release version.
    Sorry for any inconveniences caused.

    Would you like to be added to the J-Link software update notification list,
    so you get informed automatically when the new version becomes available?
    Subscribe: segger.com/notification/subscribe.php?prodid=7,94

    Best regards,
    Nino
    Thank you, Nino. I look forward to trying out the fix.
  • apluscw wrote:

    SEGGER - Nino wrote:

    Hello Tharon,

    The fix is applied and it will be available with today's release version.
    Sorry for any inconveniences caused.

    Would you like to be added to the J-Link software update notification list,
    so you get informed automatically when the new version becomes available?
    Subscribe: segger.com/notification/subscribe.php?prodid=7,94

    Best regards,
    Nino
    Thank you, Nino. I look forward to trying out the fix.
    Nino,

    I can confirm that I no longer get the unknown command issue, but the connection is not reliable. On an XP machine I can keep it up for a few minutes but eventually it drops out and on a Win7 machine it drops out pretty quickly.
    I am starting to question if the remote link feature is production ready. I have been instructed to not put a lot of time into working with it, and management is questioning how much we can rely on Segger for our work, and whether Segger is available for all the platforms we may be interested in.
    I will look and see if future releases have any changes that suggest improvements in reliability.

    Regards,

    Tharon
  • Hello Tharon,

    We do not see any stability issues with the IP connection through the Remote Server.
    If you are seeing problems, we are always willing to help and interested in making our products better and more robust.
    So if you could describe a bit more on what actions you see the connection stability issues, it would help us to boil down the problem.

    May I ask you one question?:
    If things are really time critical and you are a commercial + professional J-Link user, why do you go through a forum which explicitly says that there is no claim for support and no guarantee to get an answer at all, instead of going through the official support channels?


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.