I use the Red Pitaya STEM 125-14. Recently, I change the RedPitaya ADC clock to external clock from FPGA, by moving R25 and R26 to R27 and R28.
But, when I turn on the RedPitaya again, I think the CPU is hang (Red and Orange LED is not blinking). I see in UART console, the boot process stops at this line: "Starting Registering Red Pitaya boa...ss and IP address to a server..." This is the complete boot log.
I have replace the SD card with another RedPitaya's SD card, but the problem still exists. I have modified the ADC clock source in red_pitaya_top.sv to the external clock, then replace the bitstream file, but the problem still exists.
Does anyone have any idea why this might be happening? (is it because of the RedPitaya ADC clock?)
How to get the RedPitaya work after chaging the ADC clock to the external clock?
I solve this problem by re-installing the OS with the latest version 0.98 build 617 (redpitaya_ubuntu_17-11-35_01-sep-2017).
Related
Host machine: Debian 10 running NoMachine 7.2.3
Settings:
Specified H264
User Hardware Encoding enabled
Use Specific Frame Rate enabled (60FPS)
Use Acceleration enabled
Client: Windows 10 running NoMachine 7.2.3
Both machines have monitors attached.
Using NX protocol for connection.
FullScreen / Scale to Window / Desktop is currently 2560x1440 (reduced from native while testing this issue)
Specific issue:
I do a ton of work in the terminal and when viewing desktop via nomachine, the terminal caret is randomly not visible. The same issue is less noticeable with right click menus and other areas of "visual updates in small screen space." If this were another remote desktop vendor I would try to find the "don't update just regions" setting to force the entire display to update regularly, but I can't find similar settings for nomachine. I have a dedicated gigabit connection between the two machines with no other traffic on that line, so bandwidth is not an issue.
To recreate:
I disabled caret blink (using universal access / accessibility settings) so the caret is a solid block in terminal / vi. If I edit a text file in vi and move up and down, the caret will only update visually every other line or so (verified on the physical screen it is moving correctly). Same if I highlight or insert, etc. You inevitably miss a character or so or lose your place).
I have tried changing speed vs quality slider, resolutions, swapping from h264 to VP8, etc.
I have disabled:
multi-pass display encoding
frame buffering on decoding
client side image post-processing
Nothing seems to change this specific issue. Yes I can make dragging a quarter-screen-sized terminal window smoother, but that doesn't help me follow the caret in vi/vim. Both machines are nicely spec'd (client has 16G / RTX2080, server has 32G / GTX1080)
Is there a way to get nomachine to update all the screen all the time, or at least better refresh small areas like a terminal caret?
(OP): Based on a night of troubleshooting, the issue seemed to be either:
An issue with the Debian install of the nvidia drivers
The server machine is a laptop with a broken main screen (but with an HDMI external monitor plugged in). The Debian X-server may have been confused as to whether it was headless or not and caused issues with nomachine (which tries to detect headless and start a virtual session).
The solution to this exact problem would be to disable the GUI and force a virtual session, per https://www.nomachine.com/AR03P00973 (dummy dongles won't work because the laptop's main display is not a standard plug).
In my specific case, I needed GUI access on the server at times so I couldn't use the above methods, and I could not remedy the problem with Debian, so I wiped the system and installed Ubuntu 20.04, which is more forgiving with graphics drivers and monitors. After setting up the Ubuntu system as similarly as possible to the Debian system and letting the proprietary nvidia drivers auto install, nomachine connected at the same resolution and worked perfectly, without the lag in small screen areas.
Symptom: When I select "program flash" menu from the IDE, it starts working, but fails on a random point. Sometimes it erases flash successfully, sometimes fails earlier (see logs below).
History: It was working for weeks. When I uploaded my program, it was running, printing stuff to the UART port. Then, a nice day, flashing has stopped. I've tried, but it printed various errors. Next day it was working again (without any fix), but only for 2-3 days, then stopped working forever.
Diagnosis: In Vivado, I can see the device, it looks healthy. I checked .bat scripts, they set the environment and finally calls rdi_zynq_flash.exe, which is responsible for the whole flashing process (using server on localhost). From this point, I have no chance to know what is really happening under the hood. I was playing around with the XSCT tool, but I have no idea what should I check.
Configuration:
Board: Xilinx Zynq 7000, ZC702
IDE: Vivaldo 2020.1, on Windows 10
program type: standalone (not Linux), only ARM code, no FPGA used
programming mode: QSPI (switch 4 is on, others are off)
The errors are:
unrecognized JEDEC id bytes: 10, 01, 00
unrecognized JEDEC id bytes: 68, 03, 00
Failed to read boot mode register
ERROR: Flash Operation Failed
zynq_qspi_irq_poll: Timeout
See full logs for more details.
Solved automatically. I don't know why, I moved some cables, turned switches on and off. Maybe, it was a hardware issue.
If you have better answer, please, leave here.
I've flashed the MicroPython into the NodeMSU board based on 12E chip and have used the screen command in the terminal on OS X to run the REPL. It works a few seconds and the REPL resets.
I have no idea where is the problem ( I can write a few commands when the all my work clears and I see the MicroPython console from scratch.
without more information, this is a difficult issue to diagnose. basically, there are 4 possible causes of this behaviour:
power fluctuation causes the board to reset.
the board resets because the reset pin is physically set to gnd
the board resets because the reset pin is logically set to gnd
the function machine.reset() is called
steps to diagnose:
try a powered hub, separate power supply, different usb cable, different usb port to power your device and observe if the reset happens
inspect the board. see if there is a solder bridge between the reset pin and gnd (next to each other as seen on this image or between the pins on the reset button
and 4) here you need to look at the code in boot.py and main.py; both located on the internal filesystem on your board. You can get those files using webrepl of using the following code:
print(open('boot.py').read())
print(open('main.py').read())
If you print the content here we can inspect it with you.
alternatively, try reflashing micropython using the latest .bin from micropython.org and see if the clean version of micropython corrects the issue.
I am trying to upload the blink sketch to a new arduino nano v3 (technically it is the iduino knockoff from geeetech) with atmega328 but I keep getting the infamous "avrdude: stk500_getsync(): not in sync: resp=0x00" error... How can I avoid this error and get a successful upload?
Here is what I know:
1) I have installed the ftdi drivers according to the ftdi
instructions on the nano.
2) In the arduino IDE it recognizes the
com port. I have both correct port and correct board selected.
3) I shorted my Rx and Tx together and typed a string into my serial
monitor and received it back as I should have.
4) When I attempt to upload the blink sketch my L led flashes, the Rx pin blinks 3 times,
and then I get the error message and the modified version of the
sketch (I just extended the delay) doesn't go through.
5) This piece of information might be inconsequential but my nano is in a perpetual
state of blinking as if it had let me upload the sketch once... I did
try to upload the sketch before I installed the drivers.
I think that is all the relevant information but ask away if it is not. Thank you so much.
Thankfully I found that it was a simple dumb fix after all. I got out the magnifying glass and upon close inspection of my chip discovered that it was an atmega168 and not an atmega328 like I had originally thought it was.
funny coincidence, i found this article in hackaday.com:
"Frustrated with one of the greatest failures to become an Arduino
tinkerer, [psgarcha] took a good, long look at the Uno board. He
glanced over to an Arduino Mega board. Something looked different. On
the Uno, the resonator had blown off. Problem found, at least."
link
Hope your resonator didn't blew off.
Actually on windows platform this error is very often the only solution is to reinstall arduino driver
I am using Bhash Freeduino, what worked for me was
The Pro and Pro mini setting
AtMeta328
/dev/ttyUSB0
I've installed JDK, Android SDK and Mono Android for Visual Studio 2010, I've created an empty solution and I got the emulator up and running with Android 2.3.3 - so far so good.
When I try to deploy (F5) the app to the emulator, it connects to the emulator, and all goes fine until it starts "Installing the platform framework". Then it loads for several minutes, and finally throws an exception that looks like this:
I have tried googlin' it, but the INSTALL_FAILED_MEDIA_UNAVAILABLE doesn't seem to be described anywhere else.
I don't know if this is an important detail, but on my PC I have remapped my home folders (Documents, Favorites, Desktop, etc.) to folders like "D:\Mikkel\Dokumenter". It seemed to cause some problems when starting the emulator initially, but after adding the environment variable "ANDROID_SDK_HOME" pointing to "D:\Mikkel.android" the emulator started up with no problems.
Please advise.
Ensure that you have enough internal and external free space in your device. You can determine the free space available with the command:
$ adb shell df
Filesystem Size Used Free Blksize
/dev 192M 32K 192M 4096
/mnt/asec 192M 0K 192M 4096
/mnt/obb 192M 0K 192M 4096
/system 145M 124M 20M 4096
/data 196M 167M 29M 4096
/cache 95M 32M 62M 4096
/mnt/sdcard 3G 177M 3G 32768
In the above output, /data (which is the default install location) has 29MB free, while /mnt/sdcard (the SD card, and the external install location) has 3GB free.
For Debug builds, you need to have ~40MB free (for the Runtime package, Platform package, and apps). Release builds are significantly smaller, but Release builds cannot be created with the Evaluation version.
It's plausible that if your emulator doesn't have an SD card, then Android would generate the INSTALL_FAILED_MEDIA_UNAVAILABLE error. (To add an SD card to your emulator, start the android app, go to Virtual devices, select a device, click Edit, and look at the SD Card section.)
A cursory grepping of Android suggests that DefaultContainerService.java is the controlling factor, specifically DefaultContainerService.recommendAppInstallLocation(), and that if you're out of internal space and the package specifies auto (as Mono for Android does) and the SD card is unavailable (status.equals(Environment.MEDIA_MOUNTED) is false), then RECOMMEND_MEDIA_UNAVAILABLE is returned, which is translated into INSTALL_FAILED_MEDIA_UNAVAILABLE. This still seems odd to me (wouldn't RECOMMEND_FAILED_INSUFFICIENT_STORAGE make more sense?), but this appears to be what's happening.
Possible Problems :
No Internal/ External space in the Drive(or sdcard).
Connection is lost during the installation (apk to device or emulator).
Solution :
Try to create some space( remove some apps).
Try to reconnect the phone/emulator restart (worked for me)
This can be caused by having insufficient space on the device. So it goes looking for an SD card to install on to instead. if that isn't there it will trigger this response.
I had this problem even with 1GB of free space and an .apk of 1,5Mb. What I did was building an .apk and moving it to data/app folder. This worked for me. The problem is that I think your device must be rooted in order to access this folder.
I've solved the problem - it seems that if you close the (weird) empty DOS prompt that opens when the emulator is started, the connection to the emulator is lost.
Leaving the DOS window open, everything works like a charm.
In my case, it helped me out to switch the usb connection mode. You have to "just load" the device by usb instead of providing the sd card to the pc file system.
INSTALL_FAILED_MEDIA_UNAVAILABLE
Because of low memory. Delete unnecessary files and apps.
This problem appeared for me when I installed Facabook app on my phone. so I uninstalled it and problem solved.
It is due to not enough space on the phone.
Check your build packaging In my case it was packiging all kinds of assets, psd, etc.. and the .apk file was huge and the phone did not have that much space