I have ST-LINK dongle. When I try to connect in CubeIDE with Debug icon I have an error
Error in initializing the ST-LINK device.
Reason: No device found on the target.
It happens all the time. When I use ST-LINK utility I have the same problem, but when I push down RESET switch on board I have a connection.
Pins PA13 and PA14 are not used for another purpose. The setting in ST-LINK like Core Reset or Software reset does not work.
I only have a connection when I push down Reset switch and then try to connect only in ST-Link Utility.
Where do I make mistake and what is "connect Under Reset"?
Connect under reset means that when the debug probe connects to the target the reset line is kept active, so no user code can be executed.
I would advise to keep this always on unless you connect to the running target.
One thing could be that the software that is flashed onto your STM32 disables those pins and as such you can't connect debug/program it when it has booted.
Keeping the STM under reset while trying to connect and then releasing the reset bypasses this bootup and lets the ST-LINK interface control the STM.
Related
I have one device that is bluetooth PAN capable and had success with a different raspberry pi. I think I messed up the configuration files on this new one but didn't change them before I enabled some process that I beleive created the pan0 network interface (seen in ifconfig). This is the guide I used "prog.world/raspberry-pi-pan" and I think I put in the wrong Address in /etc/systemd/network/pan0.network. I later tried to alter that interface with "ifconfig pan0 <actual IP 192.168 address that I assume is correct>. I tried to connect again and still am not recieving any info but I get confirmation that the connection is up and running on both sides. Could there be a way to restart or edit something to fix this? Look at the guide I mentioned above. Not sure how this all works after I make the config network files but it might have happened when I did the "sudo systemctl enable" command for systemd-networkd, bt-agent, and bt-network. Maybe there is another file I need to change the IP on?
I want to measure the current consumption of the uC on my STM32 Nucleo-64 evaluation board (NUCLEO-L073RZ). The manual says, that I just have to remove the JP6/IDD jumper and then connect the pins to an ammeter:
But if I just remove the JP6 jumper (no pin connection), the uC is still running (I can still debug/communicate via I2C). I would have expected, that if the JP6 is removed, the uC is no longer powered and therefore not accessible anymore...
Can somebody please explain me, where is my error in reasoning?
Here is the link to the corresponding STM32 Nucleo-64 manual (page 23):
https://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf
Connecting the USB to the debug port IS powering the MCU through the debug pod. Try removing the 2 ST-LINK jumpers on upper left an inch from the the USB connector. That disconnects the built-in ST-LINK from the MCU. That might remove the power from the debug pod to the MCU.
I found the reason: the problem was my fuse in the multimeter was broken and the irritating LED on the Nucleo is always ON (independently of the MCU is running or not)...
I am trying to establish a serial connection between the RPI3 and an Arduino. Because that wasn't working I connected a USB to TTY cable from my laptop to the Rx/Tx pins of RPI. I was eventually able to use PuTTy to connect to it.
I am running Android Things on the RPI and the android code I have running is supposed to be a loopback (reading from UART and writing back what was read).
Here is where I am confused....
When PuTTy connected I was presented with a command line console on the RPI.
How do I get the Rx/Tx pins on the RPI to just be serial connections into and from my application and NOT a way to log into the console?
Is that a bad idea? I suppose if I ever needed to log into the RPI this would make it more difficult...
I figured out what I was doing wrong...
When following the setup directions at the below site I was using the Bluetooth mode instead of the Application mode. When I followed the directions for Application mode I was able to start using UART0 for serial comms
Set the console attribute to the following in cmdline.txt:
console=tty0
Add the following line in config.txt:
dtoverlay=pi3-disable-bt
Remove the following lines from config.txt:
enabled_uart=1
core_freq=400
https://developer.android.com/things/hardware/raspberrypi.html#disabling_the_console
Beginning with Developer Preview 3, in which USB-Serial devices support added, You can use external USB-UART dongles like this instead of UART of Raspberry Pi 3.
I have the Energy Micro EFM32 ARM dev board (EFM32LG-DK3650) that I am trying to connect to with Simulink/GDB Server. The GDB Server connects just fine to the EFM board. It appears that Simulink will not talk to the GDB Server. Has anyone tried connecting Simulink to the GDB Server and had success...other than using any Board Support Packages?
I am using External Mode set in the two places required.
This is the error I receive from Simulink:
Error occurred while executing External Mode MEX-file 'ext_serial_win32_comm': Failed to connect to the target. A time-out occurred while waiting for the first connect response packet. Possible reasons for the time-out: a) The target is not switched on. b) The target is not connected to your host machine. c) The application for the model is not running on the target. You might have clicked the Stop button.
Component: Simulink | Category: Model error
I have been searching for days and reading everything in sight. It appears either that no one else has done this, or had this problem.
Thanks for any help.
I run the command wifi-menu in my archARM system ,and it already found the Wi-Fi hotspot,
but the the connection failed.
here has a photo: http://i.imgur.com/yIQpQaL.jpg?1
note: I use the EDUP EP-N8508GS USB wireless adapter.
So now,what should I do?
I've seen this problem on an x86 Arch system, this is what fixed it: Look in /etc/netctl/ and find the config for your wireless connection. Add the line WPA_DRIVER='wext'. If you already have a WPA_DRIVER line, change it and make sure it is using the wext driver. If /etc/netctl/ doesn't exist it is because you haven't updated Arch in a while, and the files you are looking for are located in /etc/network.d