I have a new installation of ARM Development Studio 2023.0. I haven't gotten to the point of requesting a 30-day evaluation license. Immediately when launching the program, the product hangs with the following dialog:
Any help would be greatly appreciated!!
I did. DS says that it is the wrong host. I don't recognize the HostIds as any of the MAC addresses in my system. The HostId is 10BF48799469 and the MAC address I used was 5C-62-8B-68-83-FC. The license manager states "The product license does not match the hostID of this system." and there is a yellow exclamation warning symbol. I tried to rehost, and just got a message saying that someone from ARM would contact me.
Hi Ken,
If you haven't already, request the rehost here:https://developer.arm.com/support/licensing/rehost
Feel free to reference this thread as justification for the rehost.
It is likely (re)issuing an eval license from a previous request.
Thanks, Ronan!
One more data point. I exited DS and launched it again. It opened the workspace fine. However, when I opened the license manager, I got an eerily familiar dialog:
Note that I put my "C:\FlexLM\license.dat" file back the way it originally was so I can run my other apps. I did not add the ARM license to it b/c I figured it would find it in Roaming. If I rename the "license.dat" to something else, the license manager dialog won't crash, but I'll still get "The product license does not match the hostID of this system." Here's the kicker -- if I move the "DS000-EV-31030.lic" file out of Roaming, I can still launch DS and open a workspace. Now, I'm not sure if DS will work when I try to do something meaningful like attach Eclipse to a debugger on a remote target.
Hi Ronan!
Rehosting was successful! That said, I'd like to get the Java NULL pointer bug addressed and remedied on my machine. In order to use DS and be able to run "Help:Arm License Manager...", I must rename "C:\FlexLM\license.dat" to something else. Otherwise, it will crash. My fear is that DS will "run" without a license for many operations, but there are a few (eg. attaching to a remote debugger) that WILL trigger a license manager query. Thank you again for all of your help.
-- Ken Crocker
Hi Ken, opening the IDE does not trigger a license checkout, however building code, or debugging a target will.
Regards, Ronan
Thanks again Ronan! Do you have an ETA for a hotfix to the NULL pointer issue? Are we in concurrence that this is a significant bug?
What happens if you add the Arm license text to your modelsim license file?
If I place the Arm license before or after the existing licenses in "license.dat", it hangs. If I make the Arm license to be the only thing in "license.dat", it succeeds. Sadly, it doesn't play well with others.
Hi Ronan! This is a little O.T. but do you know if one can install and run ARM DS 2023.0 for Linux within WSL? Failing that, do you know if anyone has successfully run a Linux toolchain within WSL from outside of WSL using ARM DS 2023.0 for Windows? In either case, references to videos or white papers would be greatly appreciated! The problem I have is that, while I have ARM DS 2023.0 for Windows compiling programs, I can't remote debug them b/c I can't get the same tool chain installed on the target that is installed on ARM DS 2023.0 for Windows. I have access to a Linux guru and he has said that we can't get there from here. Here's a link to the tool chain we'd like to use: https://support.criticallink.com/redmine/attachments/download/27164/poky-glibc-x86_64-mitysom-image-base-cortexa9hf-neon-toolchain-2.4.4.sh This runs fine under WSL / Ubuntu or native Ubuntu.
Thanks in advance for your answer!!
I don't know if this would work, it is not something I have tried, and is not supported.
A common use case is to build on a different machine (often an automated Jenkins-type build server) than debugging, and so it is perfectly possible to load a Linux built image to a Windows-based debug session.
You will likely be prompted to fix the paths to the sources, which is a do-once operation for a given debug configuration:https://developer.arm.com/documentation/101470/2023-0/Controlling-Target-Execution/Configuring-the-debugger-path-substitution-rules
You can set this for the entire repository, you do not need to do this for individual files.