How to debugging and flashing Nucleo32 board from TrueStudio? - stm32

I'm trying to flash my code to NUCLEO-L432KC(STM32L432KC) by TrueStudio. It was failed.
[
It looks tool cannot detect ST-Link probe. I just connected it by USB cable from PC (Windows10). Code and project file are generated by STM32CubeMX.
What is the missing? What should I do?
I have confirmed following.
From STM32CubeProgrammer GUI, it cannot detect ST-Link connection.
From STM32CubeProgrammer CLI, it can detect S/N of ST-Link. But cannot connect.
From STLinkUpgrade 3.3.0, it can detect device and S/N. Also can update to V2J33M25.
From IAR Embedded Workbench, it can build and flash code and debug. No problem at all.
It looks same result using by STM32F4 Discovery kit for STM32F429 MCU.

Make sure you don't have another program such as ST-LINK utility running while you use the debugger. Some versions of the ST-LINK "hogs" the debug pod access and other programs then would have trouble connecting to it.

Install the drivers https://www.st.com/en/development-tools/stsw-link009.html
Choose the correct micro in the debug configuration window

Related

Is it possible fo brick an STM32 board through some wrong configurations in STMCubeIDE during burning/debugging?

I have been using my STM32 Blue Pill with GCC Cross Platform tools with no problem. I used ARM assembly to write a blink program, connected the blue pill to ST-LinkV2 using SWD and connected the ST-LinkV2 to my computer. On my computer, I use command line gcc assembler, linker and OpenOCD...The LED blinks. I also use STLink toolset (st-flash, st-info, etc) to communicate with the Blue Pill and it works. Then I decided to migrate to STMCubeIDE so as to get familiar with STM HAL. I create a blink project in STMCubeIDE, I program the chip, it runs the first time, but fails to connect to the chip the second time. I try to access the chip using gcc tools and STlink tools, no success - but initial blink keeps running on the chip that is refusing connection. I get a second Blue Pill board, I can connect to it using gcc tools and STlink - and I can program it using st-flash or using OpenOCD, I try to program it using the same STMCubeIDE code, it's programmed the first time and also refuses connection thereafter...refusing connection using gcc or STlink but still blinking the original blink from the first STMCubeIDE program. It says "Failed to parse flash type or unrecognized flash type". I have three more Blue Pills and I don't know if the STMCubeIDE blink code is bricking my Blue Pills.
Is it possible for some programming/debugging configurations in STMCubeIDE to brick an MCU (Blue Pill)? Thank you in advance for any information.
I tried a different computer with its gcc tools and STLink software but cannot still connect to the Blue Pills that developed problems. I tried to connect to the Blue Pills using STMCubeIDE on another computer and still no success.

STM32 debugging issue

I am using a Nucleo F303RE board. And whenever I try to debug in STM32cubemxIDE. It always shows an error for failed to start GDB error. I have attached the screenshot
I have updated the ST-Link firmware and also checked my device manager.
I have also tried disabling my windows defender.
I have also tried to change the frequency, interface, auto-connect under Debug Configuration.
Would be great if someone could help me out. I am stuck with an important demo at work.
I also tried it on Atollic TrueStudio but still no luck.enter image description here
Thanks
enter image description here
Detailed error on Atollic TrueStudio:
STMicroelectronics ST-LINK GDB server. Version 5.1.0
Copyright (c) 2018, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Target no device found
Error in initializing ST-LINK device.
Reason: No device found on target.
The reason is: No device found on target. This Means the debugger is working but it can't connect to the microcontroller.
The problem may be one of these:
The connection between the debugger and the controller. Check them first.
The serial wire debugger is disabled (I strongly think that this is the problem).
when you create a new project in CubeMX or CubeIDE the serial wire debugger by default is disabled (I expect that you burn the code for only one time :) ). So you MUST erase the flash using stlink utility or such a tool. And enable the serial wire debugger from the CubeMX in category SYS.

"No ST-LINK detected" error message, when trying to connect with ST-LINK Utility

I have a
NUCLEO-F401RE board
(with STM32F401RE)
and it has been working fine for the most part. Here recently, I followed a tutorial in the book
"Mastering STM32"
where it says to install
OpenOCD.
I had been following along before this as well, and I had been able to connect to my board and flashing it with no problem.
After attempting to get OpenOCD to work though, this is no longer possible. Every time I try to connect to my board, I simply get the following error message:
No ST-LINK detected
I have tried updating the drivers multiple times, rebooting the board, reinstalling the ST-LINK Utility, switching the USB-Cable, resetting the board and reinstalling everything and I have also tried the trick where you hold down the reset button and try to erase the chip.
So far, none of this has worked for me unfortunately.
Here you find a picture of my board.
On my desktop, I am using Windows 10. On my board, and I am using FreeRTOS.
Here you find an image of my Windows Device Manager.
I have also tried to update the firmware on my board using the ST-Link upgrade, but without luck. When attempting this, I either do not have the option to select my device (when using the .jar app) or when using the .exe app, I just get the following error messages:
No ST-Link device detected
Please connect it and then retry
I have not been able to find a solution for this anywhere, so I hope you guys can help! If you need any further relevant information, just let me know. Thank you very much.
As mentioned in other answers, the problem is almost certainly due to a competing driver (something like libusb) taking control of the device.
However, you do not need to "uninstall and reinstall everything" to select the correct driver, assuming that you have already installed it once before. Moreover, the reinstallation procedure most likely won't help, because the uninstallers usually do not uninstall the drivers anyway, and Windows will keep prefering the same wrong driver.
Instead, open Device Manager, find your STM32 STLink device, double-click to open the Properties dialog. Then click "Update Driver", then "Browse my computer for driver software", then "Let me pick from a list of available drivers on my computer", and you should see something like that:
You see that in this example, at least four different drivers available on the system are happy to service the device. The first two are generic libusb drivers, not specific to the dongle (OpenOCD is happy to use either of those, if I remember correctly). The ST-Link utility, however, wants a dedicated driver, developed by STM - those are the two entries below on my picture. If you do not see those, try installing the ST-Link utility again (no need to uninstall anything) or download just the driver from the STM website.
You can now click on the preferred driver in this list and have it replace whatever driver was assigned to the device before.
From my poor experience the "No ST-LINK detected" message in the STM32 Utility shows when you are disconnected or when other program is using a ST-LINK. So, if this start happens after installing OpenOCD try to uninstall this and try again (maybe with option "Connect under reset"?).
For your information. When you plug the cable to the PC and the board is power on then in the settings (STM32 Utility) you can see available ST-Links (even blocked). Here is example when ST-Link is blocked
From what I have learned and understood (but everyone can correct me :)), your board is divided in two parts :
The ST-Link debugger part ;
The rest with the actual microcontroller.
The ST-Link part is used to flash the microcontroller and can be used to flash any other STM32F4 device through SWD. With your picture :
The STM32 ST-Link Utility uses the ST-Link part of your board to flash it. My point is that if you have the "No ST-Link detected", the issue, I am quite sure, doesn't come from the microcontroller part but comes from the ST-Link part. And since you did say that it worked before you install openocd, I would suggest the driver part in W10 that may be the root of your problems.
Try to uninstall everything (and I mean everything) related to the STM32 (openocd, STM32 ST-Link Utility and its driver through Device Manager).
Reinstall only STM32 ST-Link utility (if you did uninstall the drivers correctly, it should ask you the permission to install the drivers during set up) and try to connect your board.
You can also try to remove the SWD jumpers (connector CN2) on your board to detach the ST-Link from the built-in microcontroller part. Since the ST-Link part is independent it will still be detected by the STM32 ST-Link Utility (but you will have to put the jumpers back if you want to actually program your microcontroller).
Just ran into this. The problem boiled down to using nucleo boards and trying to interface with them using older versions of ST-LINK (ST's search for ST-Link's first hit led me to stsw-link0004, which was not installing the right drivers). Why they don't point you to the latest greatest first, who knows.
Whenever I tried to install drivers, I could only select USB Composite device as a compatible driver, despite repeatedly uninstalling/reinstalling stlink0004.
You need to install the newest st-link e.g. stsw-link0009 (or newer).
Uninstall device (device manager had it under USB Composite Device)
Uninstall ST-LINK
Disconnect nucleo.
Reboot.
Install ST-link (stsw-link0009)
The prompt should have you install 3+ drivers. Not just 2.
Plug in. Voila.

Android arm emulator has no network access

I'm struggling with Android emulator version 26.0.0.0. The tools are managed by the Android Studio (2.3.1). All this running on Fedora FC25 with latest updates.
I can't seem to get the ARM emulator to have network access. Same works fine with x86/x64, but not arm (or arm64).
It looks like I ran to the end of my abilities to debug what's going on, and on where to continue digging.
On arm : no ability to resolve names, no ability to connect to the outside network. I'm running nc from adb shell to check the connectivity. On an arm emulator, I get timeout on host lookup when using host name, and no route to host when attempting to connect by IP. Browser application also can't connect. I run strace on the emulator and I don't even see attempts to connect to the DNS server.
On x86 : everything works. However I did have to add -dns-server option before it started working.
Debugging The most I did was running strace for both the emulators and examining the difference. AFAIU, there is an I/O thread that gets to make the requests, and it looks like it's not picking up the requests in arm case. Or the requests are not properly deposited. The thread seems to be OK otherwise, it iterates between polls and futex locks.
Of course, my whole point is to run ARM emulators (needed to debug certain ARM native code).
Debug outputs (I did remove multi-touch connection errors from the output):
arm
x86
Any pointers on where to dig, or what I may be doing wrong is greatly appreciated. I can post full trace files from running both as well.
update your Android emulator to v26.1.0, it will work fine.

getting GDB working with eclipse and the RX62N board from renesas

I have set up the board according to the RX cpu example in eclipse, and everything seemed to be working fine till I wanted to get the example running on the board. When I click the option to hardware debug, I get an error saying "Error launching GDB server. Check installation".
Am I to re install eclipse, or the GCC toolchain for the RX cpu, or anything else?
I don't know anything about your specifics (that is Renesas or the RX62N). I do use eclipse for embedded work. Typically on a new platform I would make sure I can build and download a release version first. Once you have that working then see if you can get a Debug build and the debugger running. On the platforms I am used to, you have to put in hooks (typically just a single call) to enable the debugger. For exmple on the NetBurner the debugger can run over the serial port or Ethernet so the call has to specify which version you want to use. I know other platforms use JTAG debuggers etc, Typically a dev kit for the board comes with a manual that details how to get the debugger working. I doubt that you need to reinstall anything you just need to get the configuration set up correctly.