Visual Studio 2022 ARM64

[angel]

 

VisualGDB version: 5.6.108.4723
—————— System.BadImageFormatException ——————
System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at j41.d.PatchLauncherMethods4(Object f, gn3 c, k83 a, String b, Guid e, Guid d)
at j41.d.VisualGDB.Backend.IVisualGDBNativeMethods.PatchLauncherMethods4(Object b, gn3 a, k83 c, String f, Guid e, Guid d)
at lm1.p1()
trace=[j41+d.PatchLauncherMethods4:-1, j41+d.VisualGDB.Backend.IVisualGDBNativeMethods.PatchLauncherMethods4:0, lm1.p1:68]

[angel]

VisualGDB version: 5.6.108.4723
—————— System.BadImageFormatException ——————
System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at j41.d.SetupLanguageServiceHooks(Object b, Guid f, Guid c, Guid a, String d, ku2 e)
at j41.d.VisualGDB.Backend.IVisualGDBNativeMethods.SetupLanguageServiceHooks(Object b, Guid d, Guid f, Guid c, String e, ku2 a)
at VisualGDB.VSPackage.VisualGDBPackageCommon.DoHookTextManager(DTE dte, dm obj)
trace=[j41+d.SetupLanguageServiceHooks:-1, j41+d.VisualGDB.Backend.IVisualGDBNativeMethods.SetupLanguageServiceHooks:0, VisualGDB.VSPackage.VisualGDBPackageCommon.DoHookTextManager:47]

[support]

Hi,

We are aware of that. ARM64 laptops are still very new, relatively rare, and are seldom used as development workstations. Hence, VisualGDB does not support running on the ARM64 Windows builds.

We will continue monitoring the situation and will consider supporting ARM64 development machines if they become more popular among developers.

[angel]

actually very popular 🙂 MacBook m1, m2 and parallels desktop with windows 11 arm64

program does work but on opening just popup this errors . bu everything just works very well.

 

thanks

[support]

The target-independent parts of VisualGDB (.Net IL libraries) will indeed work. However, the native parts (x86 and x64-specific) will not. Furthermore, all external tools (e.g. OpenOCD, toolchains) will have to rely on the x86 emulation, making them considerably slower. Driver compatibility could be another big issue.

So, it could be fairly easy to get it to a proof-of-concept level, but getting a reliable development environment that can be used for non-trivial projects could be orders of magnitude more complex, and may still not work out due to lack of support from external tools.

We will watch the user interest in ARM64 and the adoption of the Windows ARM64 platform by the GNU tool ecosystem, and will add support for it when there is enough momentum. If you are serious about using an ARM64 Windows host for development with GNU tools, please consider contributing to the ARM64 MinGW port. It will speed up the ARM64 adoption by the community by making it possible to do native builds of tools like OpenOCD and GCC/GDB. Once these tools are natively supported and start being used by the community, the ARM64 port of VisualGDB will make more sense.

[Undici77]

Hello, any news? I’m planning to switch from my Windows Notebook to Apple Mac Book Pro (I aleady own a fresh license on Windows machine) so I would now if you’ll full support Visual GDB on VS2022 on Windows for ARM. I did some test on a colleague machine, using trial license and situation is this:
– At open I get some errors like System.BadImageFormatException
– I successfully compile project for STM32
– I installed SEGGER JLINK for ARM

But I can’t Download Firmware in any way

So, before leave my old Notebook I would know if you plane to do something about this topic.

 

[support]

Hi,

The ARM64 compatibility should not affect firmware downloading. The regular F5 command may not work for some project types, but the Debug->Start debugging with GDB should work.

Can you confirm that the project build speed is reasonable and that running J-Link GDB server with the command-line gdb works as expected? If the underlying tools do not work on ARM64, resolving the VisualGDB issues won’t automatically fix it.

[Undici77]

Sorry, you are right: I find out JLINK is not recognized by Windows for Arm! So I written Segger! I’ll update you as soon as Segger answer me!

[Undici77]

Hi, some good news:
– Segger answer me and following this guide I fix the JTag Problem https://wiki.segger.com/J-Link_on_Windows_ARM

Now JTag is connected and configured in Windows

In Visual GDB making Test I get a dialog:
Could not find any USB…. (image attached)

If I Click Ignore output is

C:\Program Files\SEGGER\JLink\JLinkGDBServerCL.exe -select USB -device STM32H745XI_M4 -speed 2000 -if SWD -port 50204
SEGGER J-Link GDB Server V7.86f Command Line Version

JLinkARM.dll V7.86f (DLL compiled Mar 29 2023 16:48:40)

Command line: -select USB -device STM32H745XI_M4 -speed 2000 -if SWD -port 50204
—–GDB Server start settings—–
GDBInit file: none
GDB Server Listening port: 50204
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
——J-Link related settings——
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
——Target related settings——
Target device: STM32H745XI_M4
Target device parameters: none
Target interface: SWD
Target interface speed: 2000kHz
Target endian: little

Connecting to J-Link…
J-Link is connected.
Firmware: J-Link Ultra V5 compiled Mar 28 2023 17:00:28
Hardware: V5.00
S/N: 505000979
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage…
Target voltage: 3.30 V
Listening on TCP/IP port 50204
Connecting to target…
Connected to target
Waiting for GDB connection…Connected to 127.0.0.1
Reading common registers: Read register ‘r0’ (4 bytes) from hardware: 0x00000000
Read register ‘r1’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r2’ (4 bytes) from hardware: 0x94A70210
Read register ‘r3’ (4 bytes) from hardware: 0xEC150000
Read register ‘r4’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r5’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r6’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r7’ (4 bytes) from hardware: 0xF0080010
Read register ‘r8’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r9’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r10’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r11’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘r12’ (4 bytes) from hardware: 0xA5A5A5A5
Read register ‘sp’ (4 bytes) from hardware: 0xF0080010
Read register ‘lr’ (4 bytes) from hardware: 0x79C91008
Read register ‘pc’ (4 bytes) from hardware: 0x1E9B1108
Read register ‘xpsr’ (4 bytes) from hardware: 0x00000021
GDB closed TCP/IP connection (Socket 952)
Restoring target state and closing J-Link connection…
Shutting down…

So, it looks working…
Trying to download firmware pressing F5, I got the same error dialog, but clicking ignore, firmware and debug looks working.

So, there are some issue to fix but in general is working.

Now, do you plan to fix these “issue”.
They are stressful in day by day working!

 

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Sure, please try switching from the “USB Devices” view to the “Debug methods” view in VisualGDB Project Properties -> Debug settings, and then pick Segger J-Link there. It will bypass any device-level checks and will let VisualGDB run the J-Link GDB server directly.

[Undici77]

Hi,

if I did no mistake, that JTAG solution is not working (or at least I don’t know what to do)
I attached screenshots

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The command line shown on 2.png looks identical to the one you shared in the previous reply, so it should work the same way.

Please try restarting your computer, make sure no other program is using JTAG, and then try the following steps:

• Try using the test button in VisualGDB Project Properties. If it succeeds, you should be able to debug.
• If it fails, copy the exact command line shown there, and run it from cmd.exe.
• If running it manually fails, try comparing it to a working command line. Perhaps, you need some additional parameters, or have to launch it from an Administrator prompt.

[Undici77]

Hi,

Sorry for delay! I completely reinstall JTAG Driver and Reconfigure JLINK and everything is working fine now. I think, making some test I misconfigure something!

Thanks for help!
I can confirm now, in my case, VisualGDB is working!
Only some dummy errors at start!

[Undici77]

Hello! I haven’t had the chance to try VisualGDB 6 yet, but I’m curious to know if there are plans to test and certify its compatibility with Windows ARM64. In my situation, I’m working on a Mac with Apple Silicon M1, although that might not be relevant.

 

• This reply was modified 3 months, 2 weeks ago by Undici77.

[support]

Hi,

It is fully supported starting from the 6.0.4 builds (e.g. VisualGDB-6.0.4.5075.msi). We have tested it on the latest Apple M3 Max and it works just fine (that said, getting drivers for some JTAG programmers to work could be tricky).

[Author]

Posts