I'm working on STM32H7 evaluation boards (Nucleo-144 and EVAL2). My IDE is STM32CUbeIDE.
My goal is to debug remotely: run STM32CubeIDE (or another IDE) on a Linux server and connect to the board through the network.
I could run successfully the following setup:
connect the board to a local PC
launch GDBserver on this local PC
on the distant Linux server, setup the Debug Configuration to connect to the remote GDB server.
This is working fine. But I need to go further: I'd like to remove the local PC, ie. the board would be connected directly through ethernet to the network.
I've been told that there is a JTAG/Ethernet adapter for Xilinx, called Smartlynq that allows to do that, but the way it works is a bit confusing for me.
Do you know about an equivalent for STM32 ecosystem ?
Would there be another setup to debug remotely without a PC in between ?
The Segger J-Link PRO is a JTAG/SWD debugger for ARM that supports Ethernet. Like the other J-Link models, it should work fine for STM32.
Use a Raspberry PI as a debug adapter.
It would be somewhat cheaper than a JLINK Pro. If there is WLAN available, take a Pi Zero W, otherwise you'd need one of the bigger ones with Ethernet. Set it up for remote work (enable ssh, set a fixed IP address etc), then you can disable the GUI desktop, and disconnect the display and the keyboard.
Running gdbserver
The Pi has an ARM CPU which supports the Thumb instruction set but not Thumb-2, so its native gdbserver might be able to debug a Cortex-M7 controller. If it can't, then you have to install the gdb-arm-none-eabi package on the Pi.
Connectint to the target board
There are two alternatives.
Connect the onboard debug adapter to an USB port on the PI, and run openocd just the way you do it on a PC.
Bypass the onboard debug adapter, and connect some pins on the Pi directly to the SWD pins of the target. You have to remove some jumpers to disable the onboard debug adapters. There is a tutorial at Adafruit on how to compile and use openocd with native SWD support.
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
I'm attempting to connect to a Cisco 4010 network switch via it's built in usb port (which internally is a usb to rs232 adapter wired to the back of the console port).
I have installed the Cisco usb console drivers version 3.1
When I plug into the usb port, the little green LED that indicates that the console port has switched to usb does not light up.
When I run putty, and attempt to connect via serial connection to COM16 (the usb to rs232 in the cisco switch) I get:
Unable to open connection to COM16
Opening '\.\COM16': Error 1450: Insufficient System resources exist to complete the requested service.
I have tried reinstalling the drivers to no effect.
I have 3 identical switches, which give me identical behaviour, all 3 new out of the box with no programming.
Changing the Baud rate makes no difference, not that I'm expecting it to as the issue seems to be COM16 doesn't exist or similar
Putty Settings and Device Manager
With the help of a colleague, we narrowed the issue down to windows using a default usb to rs232 driver rather than the cisco one I had installed. The big clue came when I tried using putty inside a VM and it worked, while on the host OS I was still getting error 1450.
We had to compeletely uninstall all drivers, reboot, reinstall drivers manually, reboot, then attempt the usb connection again.
The last comment here describes it:
https://community.cisco.com/t5/cisco-software-discussions/usb-console-cable/td-p/3952600
I will copy the solution across to here, for easier search of the solution for the next person who has the same issue.
For WIn10 , install the setup(x64).exe from the Cisco_usbconsole_driver_3_1.zip.
Check that the Cisco Serial (Comx) is using the correct driver provider which should be Cisco. Don't use the Cypress driver.
Device Manager
To update the driver,
If you installed it already and having issues, uninstall it using the setup(x64),exe then reboot PC.
Uninstall Cisco Driver
First, disconnect the blue Cisco USB console cable. Reinstall the Cisco USB console drive using setup(x64).exe from the Windows_64 folder which was extracted from file Cisco_usbconsole_driver_3_1.zip.
Reboot PC
Open device manager to observe the driver installation. Check that you see "Cisco USB to Serial Adapter". If you don't see it repeat the above steps.
if you see above "Cisco USB to Serial Adapter". then
Update Driver
Click UPDATE DRIVER, then Browse my computer for driver software.
Choose " Let me pick from a list of available driers on my Computer." Select "Cisco Serial".
Pick driver
Finally,. connect to the COM port x indicated in the Device Manager, Ports (COM & LPT) , Cisco Serial (COMx)
I'm trying to kernel debug a physical Macbook pro device.
When my setup contains a VM, between a host MacOS and guest MacOS, its working with no problem using lldb -o "kdp-remote <guest_machine_ip>"
my boot-args on my remote (to debug) Macbook are:
user$ nvram boot-args
boot-args debug=0x44 kext-dev-mode=1 pmuflags=1 -v kcsuffix=debug
When i'm triggering kernel debug using either
sudo dtrace -w -n "BEGIN { breakpoint(); }"
or LEFT CMD + RIGHT CMD + PowerButton, the system is in halt mode, not responsive to anything (Mouse not moving, etc)
But when I'm trying to connect to the machine from the host using the lldb command provided earlier, it's not working.
I've made sure the machines can ping each other and I can set up a SSH connection.
To the best of my understanding, I had to user special Apple adapters (Real™ Ethernet adapter), so I'm using the following adapters to debug the remote machine:
https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter
https://www.apple.com/shop/product/MD463LL/A/thunderbolt-to-gigabit-ethernet-adapter
The physical connections setup looks like that:
MacOS-Debugger --(USBC to Ethernet adapter)--> Ethernet cable <-- (ThunderBolt to Ethernet adapter) <-- (ThunderBolt3 to ThunderBolt2 adapter) <-- MacOS-debuggee
Generally for the debugging I used the following tutorial, which worked for VM debugging:
https://knight.sc/debugging/2018/08/15/macos-kernel-debugging.html, I didn't find the exact KDK version, but I don't think it should be the problem here
My debugger is BigSur, and my debugee is Catalina
Any ideas to what the problem may be will be helpful
Your hardware setup sounds fine. Note that you don't necessarily need a direct ethernet cable connection, you can use your normal office-/home-wide wired network, it's fine to have a switch (or even more than one) between debugger and target. The debugger machine can even be using wifi as long as it can reach the target's wired network connection that way, though it's not recommended. The Thunderbolt Ethernet interface need not be Apple branded, but its driver does need to include kernel debugging support. In practice, for example, I've successfully used the Ethernet port in a OWC brand Thunderbolt Dock as well. Using one of Apple's own adapters of course guarantees it will work.
If the boot-args on your target machine are the same as what you used in the VM, that's probably where your problem is coming from. You should specify the device to be used for kernel debugging, using the kdp_match_name= option. Use the ifconfig command in the Terminal to work out which of the listed devices is your Thunderbolt ethernet adapter (enX), possibly based on the IP address. en0 is typically wifi in Mac laptops, so you're usually looking for X > 0.
So you'll end up with something like kdp_match_name=en1 added to your boot-args. Make sure to reboot the machine cleanly before attempting a debugging session after updating the boot-args setting.
A few more comments:
kext-dev-mode=1
This option no longer has any effect. It only existed in OS X 10.10. You can remove it.
I didn't find the exact KDK version, but I don't think it should be the problem here
Having a KDK version that doesn't match the target's exact kernel binary UUID will not prevent a connection, but it will prevent you from doing any meaningful debugging as the memory layout of threads etc. will not be available.
My debugger is Big Sur, and my debuggee is Catalina
If you ever run Big Sur on your target, make sure to add wdt=-1 to your boot-args or the hung/crashed machine will reboot before you get a chance to connect with the debugger.
I'm fighting strongly against a problem that is making me crazy.
I’m extensively using QEMU over a Win7 64bits machine for running different Linux VMs (Debian, Raspbian).
In the past I configured the network following the QEMU instructions using the OpenVPN TAP device and network bridge in Win7 : it ran perfectly and the Linux machine was able to connect the “real world” networks, internet and so on.
In the last few days, on the contrary, this nice behavior stops working. The Windows situation is unmodified (the OpenVPN TAP driver settings are the same, the bridge is still there, when the bridge is active Windows still see the network, the TAP driver becomes “busy” when the QEMU VM starts as usual, the QEMU startup scripts are still the same…), but the emulated Linux system (whatever image I use) is unable to connect the network.
The “eth0” interface is active but unable to get the IP address from the DHCP and also using fixed IP address doesn’t solve the problem, since the IP address is not seen by the “real” network.
I have tried to uninstall and reinstall again the OpenVPN TAP driver, to downgrade Win QEMU to the previous version, but no way !
The only change that I made in the HOST configuration has been to install GNS3 (with its own TAP driver), but without including the QEMU VM in any GNS3 network.
Does anybody have suggestions regarding what kind of checks I have to do on QEMU in order to solve the problem ?
Any help will be appreciated
Regards
Ugo Poddine
I was finally able to get out.
I was forced to restore a previous system image : all attempts to uninstall and reinstall the OpenVPN TAP driver were useless.
The problem is probably due to the update of the OpenVPN TAP driver : with the v.9.0.0.9 no problem, but updating to the 9.21.1 seems to have generated the problem.
I'm now able to use again QEMU and GNS3 in network.
But what a strange case !
I want to debug an app remotely on Windows RT (though this applies to any remote debugging, I guess), I don't want to open up my WiFi connection wide or handle complex software configuration every time I connect (firewall etc.).
I thought that maybe by using an Ethernet connection between my Surface and my dev machine, I could make the remote debugging work on top of that. Installing an Ethernet USB dongle on top of Surface seems to be easy, but I can't figure out how to make my dev machine actually find the Surface computer on it.
My set up is simple, dev machine connected to ethernet cable, connected to USB dongle, connected to Surface (Windows RT). Even when disabling WiFi, the remote debugger cannot find the debugee.
Do I need to manually set up the IP address or something?
Do I need to manually set up the IP address or something?
That's what I was thinking. What happens when you try to ping one machine from the the other? Does either machine run a DHCP server? If not you could run a DHCP server (probably on your dev machine) or setup a static IP address. Setting up DHCP may be harder at first but more convenient if you need to connect your tablet to other networks.
For testing it might be helpful to wire both devices to a router so you can configure and test Remote Debugging separately.