I am try to program or upload code to a nrf51822 breakout board using st link v2 mini with openocd. I have been following the blog post tutorial of http://icarus-sensors.github.io/general/starting-with-nRF51822.html. However, i couldnt get the connect to the device using openocd. Error message is attached below. Any idea what is wrong? Or, is that any other easy way i can program the nrf51?
openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.9.0-00073-gdd34716-dirty (2015-05-19-09:55)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
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
Info : STLINK v2 JTAG v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.268965
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
nrf51822 breakout :
http://www.newegg.com/Product/Product.aspx?Item=9SIA7BF37Z1712&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle--Gadgets--Srad+Tech-_-9SIA7BF37Z1712
st link v2 mini :
http://www.electrodragon.com/product/st-link-v2-programmer-for-stm8-stm32/
The important message from openocd is: "unable to connect to the target".
It means that openocd has successfully connected with ST-Link, but connection between ST-Link and nRF51822 was not successful.
There can be many reasons causing that:
Incorrect connection between ST-Link and nRF51822 (wrong pins, bad connection between wires and pins, damaged wires, maybe even too long wires)
If the chip uses external power supply, it can be a problem with the supply (you usually also have to connect ground pin of ST-Link with ground pin on external supply even if not using ST-Link to power the chip while flashing)
Faulty ST-Link (I've damaged one by mistankingly connecting ST-Link to external voltage on my breadboard)
Faulty nRF51822
Related
I want to open a USB camera with OpenCV in C++ operating on Linux Mint 18.3.
The Camera is plugged in and works fine with the SoftwareSuite by Common Vision Blocks.
From command lsusb I got the following output:
Bus 002 Device 005: ID 1ab2:0001
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0cf3:e300 Atheros Communications, Inc.
Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The first entry seems to be the camera because the entry doesn't exist if the camera is unplugged. But I don't understand why there isn't a name shown.
Then I found on the internet that the USB camera is found under the path:
/dev/v4l/by-id/ or /dev/v4l/by-path/. The entry for /dev/v4l/by-id/ is:
usb-CNFEH73N3462520017B2_Integrated_Webcam_HD-video-index0
and the entry for /dev/v4l/by-path/ is:
pci-0000:00:14.0-usb-0:12:1.0-video-index0
So I want to open it with OpenCV by using:
VideoCapture
cap("/dev/v4l/by-id/usb-CNFEH73N3462520017B2_Integrated_Webcam_HD-video-index0");
I use Clion as an IDE and run it normally as root, but in both cases I get the following error:
GStreamer Plugin: Embedded video playback halted; module source reported: Could not read from resource.
OpenCV Error: Unspecified error (GStreamer: unable to start pipeline) in cvCaptureFromCAM_GStreamer
/opencv-3.0.0/modules/videoio/src/cap_gstreamer.cpp, line 773 terminate called after throwing an instance of 'cv::Exception'
How can I open the USB camera and being on the right way to open it with dev/v4l/?
You should open a device by int id. Try with:
VideoCapture cap(0);
In fact, passing a string OpenCV expects to open a playback file, an MPEG file for example, as described in the documentation.
This is working but the problem is that the opened camera is the integrated camera, the one reported by lsusb as:
Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
which actually is /dev/video0, linked by:
/dev/v4l/by-path/pci-0000:00:14.0-usb-0:12:1.0-video-index0
Instead the lsusb entry listed as:
Bus 002 Device 005: ID 1ab2:0001
which is the externally plugged camera, seems not recognized as V4L device. I don't know "SoftwareSuite by Common Vision Blocks", so I have no idea, whether this software is able to work with it as RAW device.
I have a Raspberry PI B+ with a C++ application that is able to communicate with an Arduino. I'm able to read, write, serial connection perfeclty stable.
Now, I bought a Raspberry PI3 in order to have more performances and wifi integrated.
After a lot of time spent, I got the QT application working again but the serial communication wouldn't work.
I connected the serial monitor of Arduino IDE and checked that with RPI 1 it is working fine, and I saw all messages sent following my protocol, so I'm sure that I can analyze what I'm writing out of Raspberry P3.
Unfortunaltely, I receive only weird characters:
I tried different baudrate, for example 115200 and 9600 (expected baudrate!) but the result is different but equally wrong.
I would like to report what I did in my Raspberry P3:
I disabled the serial port for the console (as I understood on the web)
This settings would modify automatically the option:
enable_uart=0
it's strange because in the web I found who is suggesting to enable, who clearly write that it should be disabled because refers to "console over serial".
Then, I added some lines (you can see into red shape) in order to move the bluetooth handling in the miniuart, fixing the cpu frequency to 250 and fixing the default baudrate to 9600.
Then, I disable the bluetooth with this command:
I'm really not sure of that but.. something suggested in some posts.
Finally, this is the setup in my QT c++ application:
Where I changed the name of the port to "ttyS0", (same "serial1").
So.. what I would like to achieve is setup my pi3 serial communication as was working with piB+, connected on same pins GPIO14 and GPIO15.
Doesn't matter to bluetooth, I will not use it.
What I miss or made wrongly?
The PINOUT of Raspberry PI3 seems equal to PINOUT of Raspberry PI B+:
And the PINOUT of Raspberry B+ is:
But I found one interesting thing:
It seems the configuration somehow is wrong because GPIO14 and GPIO15 are both INPUTS !!
I finally fixed!
As I wrote, I found many suggestions on the web but quite often discordant.. so I will report here how I setup my Raspberry p3 in order to work fine.
1) Upgraded my system
sudo apt-get update
sudo apt-get dist-upgrade
2) Enabled the UART console
sudo raspi-config
Advanced options --> serial:
Note: it will automatically set 1 the enable_uart in the file config.txt.
3) Edit config.txt
sudo nano /boot/config.txt
I added basically one line in order to disable the bluetooth port (not used in my case)
I also removed the limitation of cpu frequency to 250, found many times as hint in forums, as you can see it's commented (#).
You can also see the setup of "enable_uart=1" done with raspi-config interface.
4) Edit file cmdline.txt
sudo /boot/cmdline.txt
I removed the piece of string where there was something like:
.... console=serial0,115200 ....
5) Application refers to serial0
6) DONE !
I Hope this step-by-step guide works for someone else or in general will be helpful.
I am building out a monitoring and automation system for my various greenhouses in the garden. Due to the number of devices that need to be controlled and monitored rather than purchasing additional Raspberry PIs I decided to go with a GPIO port expander and make use of the existing Raspberry PI hardware.
I have however managed to hit a "wall" when it comes to reading the DHT22 Temperature and Humidity sensor when I connect it up via the MCP23017. I know I have the MCP23017 connected correctly as I am able make LEDs flash and relay switches turn on and off.
None of these require reading data from the device connected though and this where I am running into the problem and would really appreciate any help or advice.
I am running a Revison 2 Raspberry PI A, sudo i2cdetect -y 1 shows MCP23017 connected to 0X20.
I am using Python 2.7 for the coding, using the Adafruit_DHT module and for addressing the MCP23017 I am using the wiringpi2 module. Although I am open to other suggestions here with regards to using wiringpi2.
The Adafruit_DHT uses the following syntax to connect to and retrieve information from the sensor:
import Adafruit_DHT
sensor = Adafruit_DHT.DHT22
pin = 7
humidity, temperature = Adafruit_DHT.read_retry(sensor, pin)
The above works fine when connecting directly to one of the "standard" GPIO ports. However I have not worked out how to address the additional new GPIO ports in this same manner i.e.
I have tried the following with no success:
import Adafruit_DHT
import wiringpi2
wiringpi2.wiringPiSetupGpio()
wiringpi2.mcp23017Setup(65,0x20)
for n in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16):
humidity, temperature = Adafruit_DHT.read_retry(sensor22, wiringpi2.digitalRead(n+64))
print n, humidity, temperature
So the above cycles through each new port, however I don't get any results back, as I say if I connect the device directly the GPIOs on the PI is works fine. I suspect the issue with how I am telling the driver which PIN to use.
I would really appreciate any advice or help on this issue. As I said I am open to other ideas on how to use this DHT22 with the MCP23017.
After installing debian in VMware and installing all librarys required to run OpenGL applications with freeglut, I used glxgears to make sure everything works fine.
# glxgears
3426 frames in 5.0 seconds = 685.171 FPS
3562 frames in 5.0 seconds = 712.339 FPS
...
XI0: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 33172 requests (33170 known processed) with 0 events remaining.
glxgears seems to be running fine. It displays the gears roatating in a window even though the above error appears after clicking on "Close" on the glxgears window frame.
But when I attempt to execute a simple OpenGL program using freeglut3, I get the following result:
# ./program
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 36
Current serial number in output stream: 35
A program which works using all the same files and libraries on a non-virtual machine, not available for me at home.
How can I resolve this issue? Is this a common problem with running OpenGL programs on virtual machines?
This is a cryptic way of your GLX server telling you: it has never heard of glXCreateContextAttribsARB (GLX OpCode 34). In other words, your system does not support GLX_ARB_create_context. The best way to explain why this is, would be to run something like glxinfo -v and add the output to your question.
It is possible to create a working context without this extension on your system as glxgears is clearly demonstrating. I have to imagine that freeglut3 should be smart enough not to use the extension if you do not request anything fancy from it (e.g. do not ask for a core profile context or a specific major/minor version). If it is not, then you will have to find a more sophisticated GLX implementation or use a different framework.
I work on specialized voip application.
It uses TLS as signalling channel and (S)RTP as media channel in calls.
There is a audio output module written that uses DirectSound to play & capture.
Audio module is resistant to audio errors. If it detects smth wrong -
1) the problem audio device is closed
2) main application is notified about problem
3) customer can select another audio device.
Works good most of time.
But sometimes the sequence "remove / wait 10-20 seconds / insert USB Jabra headset" results in interest thing. There is no more incoming RTP packets or they are corrupted.
OS can send ICMP reports about non available port to remote peer even.
I checked with DevPartner and DrMemory error checkers - but there weren't hints in their reports.
I think it can be driver or Windows issue. It is reproducible on other systems sometimes.
The question - how can I investigate this issue? Maybe there are tools that show audio driver activity inside Windows?
Thank you :)