I'm trying to flash a basic LED blinking program to my Nucleo F413ZH board using the STM32CubeIDE, but whenever I try to debug it says:-
"No ST-LINK connected! Please connect ST-LINK and restart the debug
session."
The board has the PWR and COM LEDs blinking, meaning the USB I've connected to the board is providing power, I just can't upload any code.
I've tried using the ST-LINK upgrade firmware (https://www.st.com/en/development-tools/stsw-link007.html) to install new drivers as that's what some people online have suggested but the program won't respond once I've downloaded it, which seems to be a side issue of not registering connectivity.
I'm not sure whether this is an issue with drivers or if my hardware is busted. I'm using macOS Big Sur.
In Windows 10 this problem occurs as a result of an incorrect driver priority as pointed out in this post. Error in initializing ST-Link Device - Failed to connect to device perhaps this solution might point you in the right direction. I have set up several new M1 Mac Minis in the past few months for clients, Big Sur and the new M1 have several compatibility issues like slow network drive access and flashing screens, the Android M1 chip has dramatically less external connectivity which is why they went from 4 thunderbolt ports on the last intel Mac Mini to just 2. I would not be surprised if Big Sur is the core of the problem. Try a different computer if you have the opportunity.
I was also getting the same error on ubuntu system while using stm cube ide, with st-link v2 programmer.
blue led was continuously blinking.
but solved the error just by reconnecting the usb-extention-hub, now when connected blue led is on (no blink), and now i can program and debug the target.
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 am developing on an ARM Mbed board which connects to my Windows laptop over USB. I've just moved to a new Dell laptop running Win 10 [from a Dell laptop running Win 7] and I find that the laptop resets my development board every 15 minutes.
There are two things that will cause the ARM Mbed board to reset:
powering down/up the USB connection
sending "break" via the USB serial driver.
When the reset occurs there is nothing of note in the Windows event logs. I have all of the "allow Windows to power me down" boxes unticked on the USB hubs in System devices and in the Control Panel power management options.
Does anyone have any suggestions on how I (a) debug what's going on or (b) fix/workaround the problem? I've not yet tried connecting via a powered USB hub, will do that next...
I had the same issue using a FRDM-K64F running mBed and communicating over a USB COM port to a Windows 7 Dell machine. The communication would sometimes drop out. As #Rob suggested, uninstalling the Dell Support Assist Agent completely fixed the issue.
Just adding this answer as it was very difficult to find any information using google.
Another note in support of this solution for google...
I have a Dell 5480 running Windows 10, and started using from ST Nucleo boards on it. I've used the exact same boards at work, with no problems. Every 15minutes or so the board was reset.
I tried disabling the Dell Support Assist services but this did not seem to fix the problem.
Removing the programs did make the Nucleo work.
I'm trying to use my real ice board under mplab 8.83.
I have already fixed some issues thanks to the microchip forum but sadly I have one last error that keeps coming up.
Few minutes ago it was :
Target Device ID not detected
and now that is not showing anymore but I get :
Target Device ID (00000000) does not match expected Device ID (00004c40).
I have switched the driver from MPLAB X to MPLAB 8, the self test of the real ice is working just fine. I also have tried to connect/disconnect the board. I have also tried with a ICD2 without success.
I am working with Windows 7, 64-bit.
It has nothing with Real ICE or ICD2 since it complains about device on your target board. You have to check connections between debuggers (ICD2, REAL ICE...) and hardware. If connection on ICD header is OK, next you have to check is power supply on hardware board.
Eventually I was able to solve my problem.
It turns out, that having forgotten to install the MLA library, Windows was considering the REAL ICE as a common usb device (such as thumb drive). It was listed as "Custom USB Device --> WinUSB device" in the Device Manager.
After re-installation of everything (MPLAB, C18, MLA) , the REAL ICE is listed as "Custom USB Device --> Microchip Custom USB Device" and it works perfectly !!!
I bought my Arduino Uno R3 a few months ago. It's been working like a charm since then, but today, it stopped interfacing with my computer. Let me be more specific. I have a 2013 Macbook Pro Retina with OS X 10.9 (Mavericks). It has the latest Arduino IDE installed.
I was using it today and after uploading a simple sketch (it worked for a little while) my Mac stopped recognizing it, and since, I haven't been able to access it. The LED connected to Pin 13 stays on 100% of the time. The RX/TX LEDs don't flash, but the main functions of my sketch (other than the serial functions).
Have I screwed my Arduino's Serial chip? What can I do? I am only 15, so another $30 is a little bit too much to spend to get another one.... :)
Thanks!!
UPDATE: I forgot to mention that I have tried my other Windows computer, and another cable, just to rule out those possibilities.
That is a very common issue with Arduino. I used to face that problem all the time while using Arduino. Though I never really found a solution for this, the problem did go away after sometime. Did you try resetting the uC using the reset button on the board, or restarting the IDE or your system if neither worked?
Make sure you have chosen the right COM port. On a windows system you can do this by going to device manager and look for the ports tab under it.
I recently purchased an Arduino with an atmega1280 on it. I did not get it to use the Arduino IDE but just as a handy board to use with AVR Studio and my Dragon.
I purchased a new computer around the same time and it is running windows 7 64bit, I downloaded AVR Studio 5.1 and plugged in my Dragon. I upgraded to the latest firmware as it forces you to do. I then connected the Dragon to the Arduino and I get the following error:
[ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.)
I have verified the ribbon cable pinouts are the same on both ends and have continuity. Pin 1 goes to Pin 1 and so forth. AVR Studio can read the 5.0V on the sense line but that is it.
I then installed libusb-win (1.6.2.0) and used avrdude to get a more descriptive error:
pasebin output
I have tried to wire up an atmega8 and atmega128 on breadboard with ISP and JTAG connections and I get the same errors as above but it makes more since so troubleshoot the PCB to PCB connection issue to eliminate any mis-wireings I may have.
Any idea where to start looking for the problem???
One thing is the power on the JTAG header, and another is on the actual chip. Could you try checking connections all the way from the AVR to the JTAG-pins? In my experience, there are almost always bad wiring, even if you think it is perfect.
When that is not the case, the AVR is not getting power.
Are you trying ISP or JTAG or both? Does the AVR support JTAG?
Is it ISP extracted from a JTAG connector?
Atmel's JTAGICE mkII documentation explains quite a bit of both ISP and JTAG.
I just recently build a board with JTAG connection (http://www.avrfreaks.net/modules/PNphpBB2/files/display_105.png), which may be descriptive on how to connect your JTAG, and this I know is working ;)