I have a BeagleBone Black rev C with kernel 3.8.13-bone50 and Debian OS version 7.5. The problem that I have is that when I connect the external power supply (5 V) and the board is also connected to USB ( for communication with Cloud 9 IDE) it shuts down after almost 5 seconds.
I searched everywhere on Internet for an answer, but nothing. I also displayed the content of the TPS65217 PMIC but nothing. Nothing that could give me an answer why the board is simply shutting down.
Can someone help me?
Some poor quality power supplies might cause the same kind of problem.
Please see below.
http://elinux.org/Beagleboard:BeagleBoneBlack#Improper_Power_Down....All_Revisions
Seems that the board didn't shutdown after changing a bit in TPS65217 PMIC INT register.
I changed the D5 bit from Interrupt Register from 0 to 1, meaning that no interrupt will be issued when power to AC input is applied or removed.
Command used:
i2cset -f -y 0 0x24 0x02 0x20
Related
I uploaded the Mecrisp Forth hex file for MSP430G2553 successfully using the TI UniFlash cloud tool.
(I've used the same tool to flash other Mecrisp Forth hex files for MSP430F5529 and TI Tiva LaunchPad, as well.)
Unfortunately, there is no response from the Tera Term, running at a 9600 baud rate.
(I've used the same Tera Term to talk to Mecrisp Forth running on MSP430F5529 and Tiva successfully.)
I paid attention to the hardware RX/TX business of the earlier G2 LaunchPad. In fact, the latest EXP430G2ET has it marked clearly on the board, and it comes with the crystal soldered.
So what am I missing?
The flash memory must be completely erased first (setting all bytes to 0xFF). It is not enough to just flash the Mecrisp Forth software.
(It is in the documentation, and I have positively observed it to be crucial installing Mecrisp Forth on an ARM-based microcontroller board, 1Bitsy, which has an ARM Cortex-M4F microcontroller, STM32F415RGT6 (it had other problems with a non-standard baud-rate, but that is another story). I had previously installed some other software on the 1Bitsy and that was enough for Mecrisp Forth to not work.)
There are a lot of possibilities, and you can try to eliminate a few of them with simple tests. For example, check the communication chain:
test the PC (Tera Term) part by connecting TxD to RxD and see if there is an echo.
test the MCU part - after reset, there is a relatively long message on the TxD - you can see it with a LED.
I am trying to get started with a ESP8266 using Arduino and Sparkfun thing, non dev board. I have cut a trace and an fitted uploading jumper. My FTDI device is one marked 'Deek Rodot'.
I can upload and run programs (blink etc), but if I connect to serial monitor, I have tried Arduino and putty, I get:
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
with the jumper on and
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
È
with the jumper off (after switch off / on)
I've been trying to find a solution for a few days and am wondering if anyone else has gotten through the same problem.
This happens with several different bootloaders I have tried.
I solve this problem by increasing the input power of my breadboard power supply which I use to power my ESP8266-12E with 3.3V. I guess the ESP8266 requires more current to operate properly. Hope this helps.
According to my GitHub Page
You can solve this problem by using timer instead of direct function call. The reason is ESP8266 need to run some commands every 1000 clock so if the function is a callback and it taking too long it needs to break into other function and called by a timer otherwise following error appears.
rst cause:2, boot mode:(3,6)
I suggest that change the title. This is NodeMCU bug (probably not ESP8266 or arduino) in my case at least.
Be aware that this is a workaround and absolutely not a solutiion.
My devkit is an Amica V3, well two of them and both seem to have the same problem.
I tried to get the device to show up to then be able to install the NodeMCU firmware.
I did this on different computers and different OS's (Windows 7/10 + OS X 10.11.4), everytime making sure I installed SiLabs CP210X drivers first.
No sign of the devkit anywhere... When I unplug it and plug it back in the LED near the WiFi antenna blinks and then nothing. I pressed RST a few times, short/long, nothing.
I really hope you tell me that I'm stupid and that I should have RTFM so I would have not missed providing additional power to the board the first time you flash it... But I doubt that this is the case.
Ugh. It was the cable after all. Seems that I have 5 cables that it doesn't work with the 6th (from my Logitech keyboard) works...
I am working in a technology Laboratory. We have 15 BBB, an suddenly, 5 of them didn't power on any more.
They stay with the power on Led on, but nothing more happens.
Picture:
What can i solve the problem?
Thank you
Prior to solve the problem, you probably have to investigate it first.
I would verify those beaglebones are still functional:
That is, checking if the beaglebone black is displaying any messages on the serial console,
The procedure for connecting a USB-to-TTL adapter is described here.
I would strongly suggest to buy the exact adapter featured in the article above on e-bay
if you don't have one.
If there were no messages displayed on the serial console, I would attempt to load u-boot from the serial port.
This can be done by connecting both P8.44/SYS_BOOT3/LCD_DATA3/GPIO2_9
and P8.43/SYS_BOOT2/LCD_DATA2/GPIO2_8 to the ground (two of P9.43/P9.44/P9.45/P9.46) using two 4.7 k
ohm resistors, powering the beaglebone with an external 5V power supply (not by USB),
and power-cycling the beaglebone - power-cycling IS required, performing a 'reset' is
not enough for the new SYSBOOT configuration to be taken into account.
You can then download u-boot from your PC using Teraterm: u-boot-spl-.bin should
be downloaded using x-modem, and u-boot.bin using y-modem, as described in the
'Boot over UART' section of this TI wiki article.
Once you have u-boot running, you should be able to reinstall your beaglebone using information available on the Internet.
If you cannot boot using the boot ROM and the serial port, this would probably be a bad sign.
I would suggest to try the procedure for loading u-boot from the serial port with a beaglebone you know is working, this is totally non-intrusive providing that you don't modify the eMMC from u-boot.
I’m doing a study project on wifi signal quality. What I want to do is use Raspberry Pi’s to monitor as many metrics as possible on packet level data. I want to do this by putting wifi adapters on monitor mode (using airmon-ng) and than capture the data about the packets using a wireless network protocol analyzer, like tshark.
What I understand from the wireless networks is that you mainly have three parts: a frame part that has the same information independent of what you’re capturing on, which contains things as frame number, frame length and arrival time. (Want to upload images but don't have 10 reputation yet...).
Then the IEEE 802.11 data which contains the necessary stuff for the network to work. When capturing on WLAN this contains the MAC addresses.
And than we have the radiotap header, which contains all kind of information (signal strength db and dbm, noise level, signal quality, TX value, and much more). This one is a bit different, since this information is actually filled or injected by the wifi adapter you use to capture the data with.
In the present flags you can find which values are actually being injected by the wifi adapter. Now my problem is that for my research I really need as much values as possible. I’ve been working for hours but I didn’t succeed in finding a way to capture with anything more than dmb signal strength (if even available). So this is what I tried so far:
The adapters I used so far are the Edimax EW7811UN, the AirPcap Classic, the AirPcap Tx and two similar alfa adapters with Atheros AR9271 chipset. The AR9271 adapters worked out of the box on raspbian (debian for raspberry pi) on the ath9k_htc driver. Putting them on monitor mode and capturing works fine, but only dbm singal strength is given (as in the screenshots above) in the capture. The Edimax was working out of the box on the 8192cu driver, however it clearly doesn’t support monitor mode. I could put it into monitor mode when booting it on the zd1211rw driver but that didn’t even give the dbm signal strength. Strange thing however, is that a friend tried the exact same Edimax adapter and he could capture, and the only difference we could find is that the lsmod says rtl8192cu and not 8192cu. Strangely, forums are saying that 8192cu is the newer version, however this friend had the newest arch linux kernel installed (newer than the raspbian). So I installed Arch Linux on the pi, but still wasn’t able to put the edimax on 8192cu driver in monitor mode. Then I found a package in the aur repos: dkms-8192cu which was supposed to have a patched version. However, after installing it still didn’t work. Also downloading the driver from the realtek website didn’t work. There is some stuff on patching on the aircrack-ng website, but it actually is mentioning injection of frames and doesn’t really look to be what I exactly need.
Than I bought the Airpcap Classic and the Airpcap Tx to see what they could do. First of all, they have zero linux support so that already is a big drawback since l need to use it from the Pi’s. However even in windows the airpcap’s only capture db and dbm noise and signal quality. It does receive some data at dbm noise level, but it’s worthless since it is always at -100 level. I can boot the Airpcap classic and tx have zd1211B chipset so I can boot them on zd1211rw driver but this also gives no dbm signal value or anything else.
So my question is, what exactly determines what’s in the radiotap header? I guess it would be all in the driver, but I need to be exactly sure before I write off every ath9_htc driver based adapter. I’m about to purchase another adapter which runs on carl9170 driver, however I can’t find no guarantee anywhere that it will give me those values. What I did find in the literature is that the madwifi driver gives (or was giving) noise levels, however it is acquired by Atheros so the project stopped and all websites are suggestion just to use ath9k or ath5k drivers. I tried to install it but I failed because it seems to be really outdate software since the project stopped.
It would be of really big help if someone can explain me what exactly determines what’s inside the radiotap headers, and also if someone could share any experience on when they did capture more than only dbm signal strength values from linux.