In my case I want to connect a ds3231 RTC device to the I2C bus on the Beagle-bone black. Wrote a ds3231 rtc device driver code using device tree overlay and I have been successful in communicating with the chip by instantiating the device tree overlay as follows : echo BBB-I2C2 > slots (/sys/devices/platform/bone_capemgr/). I have followed this link https://saintgimp.org/2017/11/05/add-a-real-time-clock-to-a-beaglebone-black/ and my rtc is working properly whenever it is powered on but if I unplug my rtc device and connect it back then its getting reset .
Related
I have been using my STM32 Blue Pill with GCC Cross Platform tools with no problem. I used ARM assembly to write a blink program, connected the blue pill to ST-LinkV2 using SWD and connected the ST-LinkV2 to my computer. On my computer, I use command line gcc assembler, linker and OpenOCD...The LED blinks. I also use STLink toolset (st-flash, st-info, etc) to communicate with the Blue Pill and it works. Then I decided to migrate to STMCubeIDE so as to get familiar with STM HAL. I create a blink project in STMCubeIDE, I program the chip, it runs the first time, but fails to connect to the chip the second time. I try to access the chip using gcc tools and STlink tools, no success - but initial blink keeps running on the chip that is refusing connection. I get a second Blue Pill board, I can connect to it using gcc tools and STlink - and I can program it using st-flash or using OpenOCD, I try to program it using the same STMCubeIDE code, it's programmed the first time and also refuses connection thereafter...refusing connection using gcc or STlink but still blinking the original blink from the first STMCubeIDE program. It says "Failed to parse flash type or unrecognized flash type". I have three more Blue Pills and I don't know if the STMCubeIDE blink code is bricking my Blue Pills.
Is it possible for some programming/debugging configurations in STMCubeIDE to brick an MCU (Blue Pill)? Thank you in advance for any information.
I tried a different computer with its gcc tools and STLink software but cannot still connect to the Blue Pills that developed problems. I tried to connect to the Blue Pills using STMCubeIDE on another computer and still no success.
In my application, I am using STm32L4R5VG as a host MCU. I want to upgrade the firmware of host MCU in run time over USB through the Android mobile app.
I have looked into USB DFU mode, but in that case, my device will enumerate as ST USB and also I need to enable the boot loader with boot pin.
In actuality, my device will connect with the Android mobile app using the CDC class device and enumerates as VCP. So I want to send the firmware file from Android mobile to host MCU over VCP and write into Bank2 of internal flash (as current code is in Bank1). Once the file transfer is done, the device will reboot on its own and check for the latest firmware and boots from Bank2.
I am stuck at how to write at bank2 securely during run time and perform self reset to boot from Bank2.
If anyone already worked on this or know about this then please guide me or point to the link where I can get details for this.
I'm trying to flash my code to NUCLEO-L432KC(STM32L432KC) by TrueStudio. It was failed.
[
It looks tool cannot detect ST-Link probe. I just connected it by USB cable from PC (Windows10). Code and project file are generated by STM32CubeMX.
What is the missing? What should I do?
I have confirmed following.
From STM32CubeProgrammer GUI, it cannot detect ST-Link connection.
From STM32CubeProgrammer CLI, it can detect S/N of ST-Link. But cannot connect.
From STLinkUpgrade 3.3.0, it can detect device and S/N. Also can update to V2J33M25.
From IAR Embedded Workbench, it can build and flash code and debug. No problem at all.
It looks same result using by STM32F4 Discovery kit for STM32F429 MCU.
Make sure you don't have another program such as ST-LINK utility running while you use the debugger. Some versions of the ST-LINK "hogs" the debug pod access and other programs then would have trouble connecting to it.
Install the drivers https://www.st.com/en/development-tools/stsw-link009.html
Choose the correct micro in the debug configuration window
I'm doing a project for my son where we're going to have a remote Pi Zero with a camera and various sensors and actuators, connected via wired Ethernet to a Pi 3 as a controller with a Scratch GUI.
Seems like I can get a local camera to send video to the background of the Scratch project, or I can get a remote camera to stream back to e.g. VLC Player using RTSP.
Being as how I want to teach my son how to build a scratch GUI on the Pi3 to remote control the sensors and actuators on the Pi Zero, I'd really like the rtsp video stream to show up as the Scratch project background so I don't have to have a separate VLC window open.
So... how to pick up an RTSP video stream and send it to the Scratch backdrop?
Anyone got any ideas as to where I could start? I have intermediate raspbian, python and Scratch skills.
Thanks in advance,
Ben
Just a wild suggestion. Maybe it is possible to access your USB camera on the remote pi zero as a local camera using remote USB (I admit I have never tried it).
This functionality is provided by the package usbip
https://packages.debian.org/jessie/usbip
You can install this package using the following command on both raspberry pi devices:
sudo apt-get install usbip
For more information about the setup enter the command:
man usbip.
I am trying to use a raspberry pi to send feature reports to a Vive tracker. However I've come across a bit of a problem when I connect both of them.
Whenever I boot up the pi with the vive connected the vive stops being tracked on SteamVR. However when I reboot the pi it tracks again despite the fact that the vive is connected via bluetooth to a pc running unity.
I've set up udev rules for the vive tracker and checked the output of /dev/hidraw0 which is empty on reboot but on boot constantly outputs, does that mean the pi is using the tracker? If so how can I find out what?
Is there a way to stop the pi from using the interfaces which I need to run my script and allow the tracker to track on SteamVR while plugged into the pi without having to reboot each time?
I've tried killing any process using the interface (through fuser) and printing logs of boot up processes and reboot processes but haven't found anything that would cause this