The development board is STM32F4DISCOVERY, which includes an ST-LINK embedded debug tool. Recently, my computer cannot identify the ST-LINK on it. The Device Manager shows that 'Unknown USB Deviceļ¼Device Descniptor Request Failed)' with a yellow '!'.Besides, the LD1(LED) on the board change between Red and Green every 5s. Below is the SCH of the ST-LINK.
ps: I've already re-install the device driver, changed the micro-USB cable and even tried on another computer. Still not work.
I had similar behavior when I shorted-circuit on 5V (of course accidentally). Please check voltage on D1, on both sides must be 5V.
Also, if the voltage is OK, I would recommend testing board on another PC.
Related
Good day
The problem:
I am trying to connect/flash/debug a Olimax STM32-E407 dev board over SWD and I am not able
When trying to connect, using CubeProgrammer, I get: "No STM32 Target Found"
What I have tried:
I have connected a ST-link V3 mini to the pinout of the the 20pin header of the Olimax board including 3.3V, GND, SWDIO (PA13/Pin7), SWCLK (PA14/Pin9) and NRST (Pin15).
I am powering the powering the board from a power supply into the power jack
All jumpers and solder bridges are in stock places.
I have also tried manually pulling NRST to ground and doing a full chip erase, but that has not worked either.
I have used these ST-link debuggers on other boards I made and it works perfectly fine
I have 3 Olimax boards and none of them work
Any help would he hugely appreciated.
Debugging problems on microcontrollers have two general common methodes.
Hardware Problems:
In this part, it is highly recommended that use an oscilloscope to monitor circuit.
Make sure the microcontroller is powered with a correct and stable power supply.
Check the soldering quality and there is no short circuit on the board (especially between ground pins and other pins).
Check the NRST pin is high when the board is powered.
Remember that this reset is active low so during programming or debugging this pin should be high. Also, check this pin is debounced with a capacitor.
Also you can check the JTAG pins signals with an Oscilloscope to check if the programmer device is working fine.
Sometimes adding a capacitor between debugging pins and GND increases the bus capacitance and solves the problem. The value of the capacitor should be found by trying.
Software Problems
Check the programmer driver is correctly installed on your PC.
Check the programming method is true(for example maybe the board is designed to be programmed with SWD, not JATG).
Sometimes reducing the programming clock of the programmer solved the problem.
If all of these methods didn't work and you are sure that the board is fine, probably the programmer is broken, so change the programmer with another one.
I have two nucleo boards (F4339ZI and F303K8) and neither of them show up as USB devices when I plug them into a computer via the USB port (CN1 - the USB micro port on the ST-Link, not the USB port for the board itself).
I have tried multiple host USB ports, with and without a USB hub, across two different computers, one running OS X and one running Linux. I have tried at least 6 different cables. The OSX machine is using a USB-C to USB-A converter (if that's the correct terminology). The Linux machine has USB-A ports.
In no case does the device show up using lsusb under Linux or system_profiler SPUSBDataType under OSX. Needless to say STM32CubeIDE and st-info can't see the boards. Other USB devices are functional.
The COM LED is slow blinking red which the manual (https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-stmicroelectronics.pdf) says means USB enumeration hasn't completed (matching what is seen from the OS level).
The boards successfully run their factory supplied blink programs when powered on.
I have tried (with the F4395I) moving JP3 to VIN so the board doesn't power up which should just leave the ST-Link running - still no enumeration though.
I tried connecting to a USB charger with JP1 off (and JP3 on U5V) and the board powers up and blinky runs. The manual referenced above says:
In case the board is powered by a USB charger, there is no USB enumeration, so the green LED LD6 stays in OFF state permanently and the target STM32 is not powered.
But everything works for me - LD6 goes a steady green as it does when connected to a computer.
Given it happens with multiple computers, OSs, cables and Nucleo boards I assume the error lies with me, the common factor in all the tests. This is my first use of Nucleo boards so I may well have a mis-assumption.
Out of frustration and lacking anything else to try I dug up every micro USB cable I could find. One had chokes on each end and magically, using that cable, everything just works as expected.
Can it be that I have at least 10 broken USB cables? I don't have an easy way to test them but I guess they might not have the data lines wired to save cost if manufacturers assumed people would only charge phones with them. I don't recall where they all came from...they have just accumulated in a box of USB cables.
Perhaps the Nucleo board sensitive to some horrible interference floating around my room?
Sorry for the noise! Broken cable was genuinely one of the things I suspected - but not 6 of them...
I currently have a pi zero which acts as a bluetooth keyboard which - when attached to a computer - types text read from the SD card. I followed this tutorial https://www.rmedgar.com/blog/using-rpi-zero-as-keyboard-setup-and-device-definition. I use only the USB "Data" port, to power it up and to send data.
This setup works really fine on nearly all computers I tested it on, just on some Windows 7 systems it is not working at all. The system where it is not working on identify the pi zero as "Unknown device" and then never "re-identify" it as the keyboard which it is supposed to be.
All other systems first identify the device as "Unknown device" and after some seconds "re-identify" it as the actual keyboard. IMO the problem is the one mentioned by scruss in this post: https://raspberrypi.stackexchange.com/questions/60056/cant-see-raspberry-pi-zero-via-usb-otg-on-windows-10
I'm looking for a possibility to fix this problem. Is there some possibility to configure the pi zero in a way that during boot it does not identify as any USB device. Maybe that during boot the data USB port acts only as a power USB port.
Or can I turn the USB port off and on after a boot so that form the computers point of view it looks like the usb devices is removed and reattached??
I fixed that with the help of a colleague.
The solutions seems super simple - just remove the usb gadget and add it again.
The code necessary is equally simple:
#Remove usb gadget
echo "" > UDC
#Add it again
ls /sys/class/udc > UDC
Recently I have installed fluxion on my Pi 2. There wasn't any problem in the installation process, but when I tried to use fluxion, (after choosing the language) I got the message no wireless cards found ....
It is strange because I was able to see wlan0 (and also connect to the internet) before I had selected language. And also the light on my Wi-Fi dongle goes off.
Is there any solution to fix this problem?
Finally, I could solve the problem. I bought a new wireless usb adapter. For those who are curious I will introduce model of the device. I purchased TP-Link TL-WN722N which is suitable for hacking tools in raspberry pi. It also supports monitor mode. For more information you can visit the official website.
I have an app that connects to an external accessory via Bluetooth. Testers have reported that the connection gets dropped when "Low Battery" alert is displayed. This was reported on iPod touch 2nd gen., so it may be peculiar to that device.
I am wondering if there is a way to run my app in debugger (connected to my computer) without charging the device. In other words, is there a way to disable USB charging of a device whose battery is not fully charged?
I have not tried it, but it is possible / likely you can do this by cutting the power cable within the usb cable.
I would buy a cheap usb extension cable (male <-> female), and carefully cut it open (remove the outer plastic in the middle of the cable without damaging the wires inside).
If you are lucky, there'll be a red cable, and that red cable will be the +5V line - if not, you'll have to use a multimeter to test which cable is pin 1 / +5V / VCC (pinout here: http://pinouts.ws/usb-pinout.html ). Once you identify it, cut that cable (and only that cable!).
Then plug your iphone/ipod into your PC using your new cable, and the iphone will hopefully still work with the debugger but will no longer charge.
As an aside, I could imagine the possibility that bluetooth is automatically disabled (or switched to a lower power mode) when the battery gets low - in which case losing the connection may be inevitable. You could try asking apple support if they are aware of anything like that.
Nope. The debugger only works when the dock cable is connected via USB to the development system, and that automatically causes the device to charge. You will have to find another way to monitor what your app is doing.
No, but you should have your user turn on logging on their test device and then send you the logs. (Or if you are that tester, turn on logging in the Settings app, under "Developer".)
Perhaps you can log the low battery message and the Bluetooth status as well.