Why does OpenOCD fail, when the ST-Link Utility works? - embedded

I am trying to use openocd to debug my stm32 bluepill (stm32f103c8t6). I have it connected with an ST-Link V2 which works fine through the ST-Link Utility (connecting, flashing, ...). When I try to use it via openocd I get the following error:
F:\Tools\openocd\openocd.exe -f "F:\bluepill.cfg"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
Running it with configurations provided by Clion yielded the same result.
bluepill.cfg
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
reset_config none separate
I tried the answers suggested in this thread without success.
What exactly does the error message mean and what am I missing here?

I had the exact same error as you have. I did a full chip erase using st link utility and it works perfectly for me now. I used this:
openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
modify it for your use on windows and let me know if it works!

Related

/include/boost/thread/pthread/mutex.hpp:111: boost::mutex::~mutex(): Assertion `!res' failed

on Ubuntu 16.04, I compiled the spinnaker SDK src/Acquisition/make, I got the "Acquisition" under bin/
When I run it, I got the error:
Number of cameras detected: 1
Running example for camera 0...
* DEVICE INFORMATION *
DeviceID: 18073382
DeviceSerialNumber: 18073382
DeviceVendorName: Point Grey Research
DeviceModelName: Grasshopper3 GS3-U3-32S4M
DeviceType: U3V
DeviceDisplayName: Point Grey Research
DeviceAccessStatus: OpenReadWrite
DeviceVersion: FW:v2.25.3.00 FPGA:v2.02
DeviceDriverVersion: none : 0.0.0.0
DeviceUserID:
DeviceIsUpdater: 0
DeviceInstanceId: 0113C726
DeviceLocation:
DeviceCurrentSpeed: HighSpeed
GUIXMLLocation: Device
GUIXMLPath: Input.xml
GenICamXMLLocation: Device
GenICamXMLPath:
DeviceU3VProtocol: 1
* IMAGE ACQUISITION *
Acquisition mode set to continuous...
Unable to begin image acquisition. Aborting with error -1010...
Camera 0 example complete...
Done! Press Enter to exit...
Acquisition_C: /softwarelib/Boost/boost_1_60_0/GCC_5_3_1/linux_cpp11/release/amd64/include/boost/thread/pthread/mutex.hpp:111: boost::mutex::~mutex(): Assertion `!res' failed
The sample code itself doesn't use mutex at all.
This error is due to insufficient usbfs memory allocation. Please refer to section 3 of the spinnaker readme as follows for info on how to increase the value to 1000:
===============================================================================
3. USB RELATED NOTES
On Linux systems, the USB-FS memory is restricted to 16 MB or less by default. To
increase this limit to make use of the imaging hardware's full capabilities, a
minor change needs to be made to the system.
To PERMANENTLY modify the USB-FS memory:
1. Open the /etc/default/grub file in any text editor. Find and replace:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
with this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.usbfs_memory_mb=1000"
2. Update grub with these settings:
$ sudo update-grub
3. Reboot and test a USB 3.1 camera.
If this method fails to set the memory limit, to TEMPORARILY modify the USB-FS
memory until the next reboot, run the following command:
$ sudo sh -c 'echo 1000 > /sys/module/usbcore/parameters/usbfs_memory_mb'
To confirm that the memory limit has been successfully updated, run the following command:
$ cat /sys/module/usbcore/parameters/usbfs_memory_mb
If using multiple USB3 cameras, the USB-FS memory limit may need to exceed 1000.
More information on these changes can be found at:
https://www.flir.com/support-center/iis/machine-vision/application-note/understanding-usbfs-on-linux

N210 not recognized under gnuradio

I have an ETTUS Research N210 software defined radio (SDR) connected to my laptop. The device is recognized under macos and also under an Ubuntu on top of a virtual box. These commands:
uhd_usrp_probe --args=addr=192.168.10.2
and
uhd_find_devices --args=addr=192.168.10.2
and even
rx_ascii_art_dft --args=addr=192.168.10.2 --freq 92000000 --gain 30 --rate 8000000 --frame-rate 15 --ref-lvl -50 --dyn-rng 70
work perfectly and deliver results. But whenever I start the gnuradio-companion with a simple flow graph, I get the following error (BOTH directly under macos and on top of VirtualBox Ubuntu):
[ERROR] [UHD] Device discovery error: unknown key format 192.168.10.2
Runtime
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address: 192.168.10.2
In the flow graph, I put the device address in the properties window of "USRP Source--> General --> Device Address".
Any ideas what I am doing wrong?
I finally found the solution in one of the replies in ETTUS forum. So I put it here in the hope it can be useful for others facing the same problem. The device address field of the USRP source in gnuradio-companion should not be filled with just "192.168.10.2" but with "addr=192.168.10.2". This solved the problem for me.

Debian Camera isn't working

I have never before worked in Debian environment. I have some problem with camera, I was looking for answers but find nothing.
I am working in virtualbox, the camera is plugged through virtualbox. I am using is my laptop webcam, Lenovo EasyCamera. When I lauch program, for example cheese, I get this message :
jakub#debian:~$ cheese
OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr
(cheese:3368): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel
libv4l2: error turning on stream: Brak miejsca na urzÄ…dzeniu
** (cheese:3368): WARNING **: Error starting streaming on device '/dev/video0'.
** (cheese:3368): WARNING **: Could not negotiate format
When cheese is working, the diode from the cam is on, so camera is working, but why Debian cannot show me the image.
I hope you will know what to do. I appreciate your help.
It appears to be the same as this issue:
libv4l2: error turning on stream: No space left on device
You probably need to enable USB 2.0 in your virtual machine and pass the device into your guest OS using a high-speed USB host controller (EHCI).
You may need the VirtualBox Extension Pack, I remember it being required for USB 2.0 in the past. I can't find any current information about that, though, perhaps EHCI support is now included already.

poclbm not reporting hashes to deepbit or slush

I run poclbm on my system but for some reason both deepbit and slush don't "see" the work being performed. My system reports about 200 megabashes per second being done. I tried mining with my cpu using the same settings, and then both deepbit and slush recognized that work was being performed.
These are the errors I am getting out of the respective mining hardware (every minute or so):
poclbm error: pit.deepbit.net:8332 22/02/2013 21:50:59, Verification failed, check hardware! (0:0:Cypress, d47b7ba0)
cgminer error: [2013-02-22 22:18:51] GPU0: invalid nonce - HW error
I am using Ubuntu 12.10 (Quantal Quetzal) with the 12.10 version poclbm with an ATI 5800 series video card. The video drivers are installed and work as far as I can tell. When I run a "aticonfig --odgc --adapter=all", the gpu does seem to be utilized with poclbm (around 70% utilization or so).
I found the solution through an irc channel (Freenode on channcel #cgminer). Basically, at least on the version of Ubuntu that I have (12.10), the 2.8 version of the SDK does NOT work properly with cgminer or poclbm. I was instructed to download the 2.4 version of the SDK. Here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx64.tgz
Some distributions require the "2.7" version so I'll put the links here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx64.tgz
I compiled it. There is no "make install" for this Makefile, apparently, so you have to manually copy the files to your lib directory:
for 32 bit: $ cp -pv lib/x86/* /usr/lib/
for 64 bit: $ cp -pv lib/x86_64/* /usr/lib/
Also copy the include files: $ rsync -avl include/CL/ /usr/include/CL/
With the libraries installed in the appropriate directories, I recompiled cgminer and then it worked. I also tried it with poclbm and it worked with that too.
Hm, I experienced the same error with pclbm and cgminer. Then I found https://bitcointalk.org/index.php?topic=139406.msg1502120#msg1502120 .. I tried phoenix and all is ok now. Hope it helps. Sry my bad english.

Using bitbake to build a custom gumstix kernel

I've a gumstix Overo which I am configuring to work with a e-CAM camera. The documentation provided by camera manufacture asks me to patch a 2.6.34 kernel and compile in Video For Linux support. When I look at gumstix user documentation they say I should execute:
bitbake -c menuconfig virtual/linux
However when I run this command I get
bacon:~/proj/overo-oe$ bitbake -c menuconfig virtual/linux
NOTE: Handling BitBake files: \ (7100/7100) [100 %]
NOTE: Parsing finished. 6382 cached, 413 parsed, 305 skipped, 2 masked.
ERROR: Nothing PROVIDES 'virtual/linux'
I'm not altogether sure about how I provide virtual/linux. Any ideas about how to fix this error?
This might be a case of out-of-date documentation. In any case, my current work around is to name the kernel explicitly: bitbake -c menuconfig linux-omap3-2.6.34
I can help with a step-by-step procedure to bitbake 3.0 kernel.
If that may be helpful for you. Using a WMware Ubuntu ...
I would stay away from convoluted build systems as bitbake. Every one seems to be inventing one... making the 'tool' to get more of your time then the thing you want to do with the tool. All of them are the same. Linus would quote on those guys:
Just don't do it...!