Forum Replies Created
-
AuthorPosts
-
Undici77Participant
Thanks: I’m using Segger J-Link so driver should be not a problem.
One more thing: are you using Arm64 Binaries (Cmake, Ninja, Compiler) or just x64 trusting Windows emulator? In my experience performances degradation because of “F**K Microsoft Emulator” is huge!
Undici77ParticipantHello! 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 11 months, 3 weeks ago by Undici77.
Undici77ParticipantHi,
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!Undici77ParticipantHi,
if I did no mistake, that JTAG solution is not working (or at least I don’t know what to do)
I attached screenshotsAttachments:
You must be logged in to view attached files.Undici77ParticipantHi, some good news:
– Segger answer me and following this guide I fix the JTag Problem https://wiki.segger.com/J-Link_on_Windows_ARMNow 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 VersionJLinkARM.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: littleConnecting 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.Undici77ParticipantSorry, 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!
Undici77ParticipantHello, 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 ARMBut 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.
Undici77ParticipantHi,
I come back to this topic after some experience with J-Link (BASE and ULTRA+) with Visual GDB and I would say that debug experience is better than warking with STLINK v3:
- No need to start 2 instance of Visual studio for 2 core and continuously download and restart 2 projects
- No annoying stucking during debug
- Faster
Obviously J-Link is expensive but time saved by not to restart every time 2 debug session, SO BUY IT!
Undici77ParticipantThanks for answer!
I found something interesting:
- CubeIde use generic script stm32h7x.cfg and download both .elf at the same time, as explained in AN8256 STM32H7x5/x7 dual-core microcontroller debugging
- Visual GDB use stm32h7x_dual_core.cfg
Can you provide a solution, in order to debug a firmware with CM4 gated on reset?
- This reply was modified 3 years, 11 months ago by Undici77.
Undici77ParticipantWatching GDB Log, it looks like I can’t start to upload firmware on M7 core if M4 core is gated.
This is log error extracted from GDB:
C:\Users\undici77\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd_hla_multicore.exe -c "gdb_port 4146" -c "telnet_port 4145" -f interface/stlink.cfg -f C:/Users/undici77/AppData/Local/Temp/tmp53C5.tmp -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2020-05-30) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 4000 kHz Info : STLINK v3 JTAG v7 API v3 M2 VID 0x0483 PID 0x374E Info : using stlink api v3 Info : Target voltage: 3.226824 Info : Unable to match requested speed 4000 kHz, using 3300 kHz Info : Stlink adapter speed set to 3300 kHz Info : STM32H747XIXx.cpu0: hardware has 8 breakpoints, 4 watchpoints Error: Target not examined yet Error executing event examine-end on target STM32H747XIXx.cpu0: Info : STM32H747XIXx.cpu1: hardware has 6 breakpoints, 4 watchpoints Info : starting gdb server for STM32H747XIXx.cpu0 on 4146 Info : Listening on port 4146 for gdb connections Info : starting gdb server for STM32H747XIXx.cpu1 on 4147 Info : Listening on port 4147 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080057f0 msp: 0x20020000 Error: timed out while waiting for target halted TARGET: STM32H747XIXx.cpu1 - Not halted
- This reply was modified 3 years, 11 months ago by Undici77.
-
AuthorPosts