We are currently developing an application for BeagleBone Black (using the standard Angstrom distro). It runs quite happily for a while (5-10 minutes) under GDB (controlled by Netbeans remotely) but at some relatively random point in time will freeze - the heartbeat LEDs stop flickering and a complete reboot is required.
One possibility is that it is simply the number of (USB) devices that is causing this. We are connected by an FTDI serial link to my development PC (there is a client application that talks to my BBB server). There is a 4-way FTDI hub with multiple devices (3 currently) on that, a further single FTDI connection with another bit of hardware attached. Also, two I2C devices. Plus mouse and keyboard.
Of course I have no evidence other than hearsay that it's USB causing the problem. My software is not causing any signals, the log file tells me very little more. I have run the system monitor application to see if I'm leaking memory but it seems well behaved and stable (though CPU did creep up). I'd like to find a way to get to the bottom of what's failing, and would appreciate some assistance.
Finally, the bottom of the rabbit-hole:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/308549
It would appear that there is a problem in the TI silicon, specifically the interrupt controller, that causes a "babble" interrupt to fire when the USB gets overly busy. This causes an attempted reset of the host and the application correspondingly dies. This explains why the issue exists in both Angrstrom and Debian - it's not a stack / driver issue at all, but a problem with the TI chip. Ouch! We are probably going to have to drop BBB as our platform of choice because of this.
The output from the debug serial console confirms this to be the case for our application:
_handle_irq+0x39/0x58)
[ 466.343796] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>]
(__irq_svc+0x3b/0x5c)
[ 466.359334] Exception stack(0xd2759cf8 to 0xd2759d40)
[ 466.368332] 9ce0: 00000000 c0849ac0
[ 466.382735] 9d00: 00000000 00000000 c07a2080 00000000 d2758000 00000002 d2759db0 00000003
[ 466.397178] 9d20: c0812610 d2758000 b405025a d2759d40 c0031241 c0030f4e 40000133 ffffffff
[ 466.411686] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0030f4e>] (__do_softirq+0x46/0x174)
[ 466.426346] [<c0030f4e>] (__do_softirq+0x46/0x174) from [<c0031241>] (irq_exit+0x29/0x50)
[ 466.440833] [<c0031241>] (irq_exit+0x29/0x50) from [<c000c8cf>] (handle_IRQ+0x3f/0x5c)
[ 466.454864] [<c000c8cf>] (handle_IRQ+0x3f/0x5c) from [<c0008551>] (omap3_intc_handle_irq+0x39/0x58)
[ 466.470777] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>](__irq_svc+0x3b/0x5c)
[ 466.486319] Exception stack(0xd2759db0 to 0xd2759df8)
[ 466.495351] 9da0: 00000002 00000000 00007d00 00000000
[ 466.509782] 9dc0: c07c81d0 c07c81d0 c07c75dc 00007d02 0000007d 00000003 c0812610 de5f4b40
[ 466.524147] 9de0: 00000100 d2759df8 c0025b2d c0025bea 00000133 ffffffff
[ 466.536019] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330)
[ 466.553005] [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330) from [<c0383273>] (clk_change_rate+0x1b/0x52)
[ 466.570813] [<c0383273>] (clk_change_rate+0x1b/0x52) from [<c03832fb>] (clk_set_rate+0x51/0x72)
[ 466.586199] [<c03832fb>] (clk_set_rate+0x51/0x72) from [<c034ba29>] (cpu0_set_target+0xf9/0x198)
[ 466.601754] [<c034ba29>] (cpu0_set_target+0xf9/0x198) from [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70)
[ 466.618890] [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70) from [<c034b33b>] (dbs_check_cpu+0x123/0x134)
[ 466.635897] [<c034b33b>] (dbs_check_cpu+0x123/0x134) from [<c034ad31>] (od_dbs_timer+0x4d/0xb0)
[ 466.651283] [<c034ad31>] (od_dbs_timer+0x4d/0xb0) from [<c003c8c5>] (process_one_work+0x1b5/0x2c0)
[ 466.667088] [<c003c8c5>] (process_one_work+0x1b5/0x2c0) from [<c003cca3>] (worker_thread+0x19b/0x258)
[ 466.683355] [<c003cca3>] (worker_thread+0x19b/0x258) from [<c003fb8f>] (kthread+0x67/0x74)
[ 466.698026] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>] (ret_from_fork+0x11/0x34)
[ 466.712148] drm_kms_helper: panic occurred, switching back to text console
[ 407.924892] CAUTION: musb: Babble Interrupt Occurred
[ 407.965570] CAUTION: musb: Babble Interrupt Occurred
[ 408.026994] gadget: high-speed config #1: Multifunction with RNDIS
[ 413.918684] musb_g_ep0_irq 710: SetupEnd came in a wrong ep0stage wait
So it looks like plugging a mouse into a USB hub and sticking that on a BBB can cause this problem if there are other devices on the hub doing IO. A colleague informs me there are issues with such things on Raspberry Pi too. Having unplugged the mouse, the software ran for well over an hour with no freeze. Plugging it back in, there was a freeze after about 10 minutes. Removing the mouse, running again, and it's been going for half an hour again with no issue.
Related
I have 2 types of ARDUINO-cards. ATMEGA 2560 and ATMEGA 328P.
In my Delphi7 (XP64 sp2) I have modified the JvHidDeviceController Unit to show the PID/VID's of the abovementioned Cards. That works perfectly. And with the use of the TComPort unit I can communicate with the selected card. No problems here.
And here is the problem:
I connect my AVR MARK II (usb-tiny). System "says" OK.
(When I run the ARUINO program I have no problems communicating with the connected card.)
I run the Delphi program (JVHidDeviceController Unit), the 2560 and 328p PID/VID appear in a LIST-box but NOT the AVR-MARK II.
I Wonder why ? Please help.
After a search on the WWW I discovered, that the UNO (328P) could be turned into a ISP programmer. And by doing so I solve 2 (sub-)problems. I got the code ("bootloader") and the UNO Stills responds to the JVHidDeviceController requests. (Final solution in reach.. ) Kris
I've been trying to make the serial communication work on my BBB for days now and I am running out of ideas.
When I use just the BBB and connect MISO/MOSI I get the signal transfer on MOSI, SCLK and CS (MISO is mainly at high level). However, when I connect the lines to my slave part it does not work. I checked the signals on the oscilloscope and they seem fine and the part which I am using as the slave is working well when I set it in parallel mode, so I believe some programming or configuration must be wrong.
This is basically what I do:
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
python
from Adafruit_BBIO.SPI import SPI
spi = SPI(1,0) #I would expect SPI(0,0) here, but I get the signal on the above configured ports
Then I set the configurations (already tried in many ways):
spi.mode = 0
spi.cshigh = False
spi.msh = 10500000
spi.bpw = 16
spi.lsbfirst = False
After that I open it and try to send data:
spi.open(1,0)
spi.xfer2([1,254])
If anyone is interested, I am trying to program the LMH6517 as slave and I already tried to ask about this at the TI forum here:
https://e2e.ti.com/support/amplifiers/f/14/t/751415
Oscilloscope images:
CS and SCLK
MOSI and SCLK
MISO and SCLK
Thank you,
JPL
I have run into some problem controlling usb1' power. as I investigated from
"https://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060" It tells me that GPIO3_13 controls usb1_drvvbus pin, which controls the usb power.
I understand that there is software method to change the voltage of this pin.
My question is that where is GPIO3_13 located on P8 or P9 expansion bays? I cannot find it on any diagrams. Is it purposefully not exposed anywhere?
You can control USB1 power from software on the beaglebone, if you are using a recent elinux.org Debian image (the necessary device tree overlay was merged in June 2015). This uses a hack to expose the usb1_drvvbus signal as a fake LED, which can then be controlled using the files in /sys.
Firstly, load the dev-USB-PWR-CTL-00A1.dtbo device tree overlay. For recent setups (where all dtbos are loaded by uboot and then passed to the kernel at boot time), this could be done by adding dtb_overlay=/lib/firmware/dev-USB-PWR-CTL-00A1.dtbo to /boot/uEnv.txt and rebooting (older kernels/uboots will need to use the older config mechanisms as described in /boot/uEnv.txt).
You can then do this:
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
When i boot ESP8266 i'm getting on my arduino MEGA serial monitor.
Fatal exception (0): e2= 0d00l(xp00v0xao1,00e0c pe80c00d0x:2= 0d00l(xp00v0xao1,00e0c pe80c00d0x:2= 0d00l(xp00v0xao1,00e0c e 0xp0= 0e)02,0d00a 0e00c00Fic00= 0p0e 0xp0= 0e)02
If i do a hard reset than it prints
Jan 8 2013,rst cause:4, boot mode:(3,6) wdt reset load 0x40100000, len 28740, room 16 tail 4 chksum 0xcd load 0x3ffe8000, len 2888, room 4 tail 4 0xeotail 0 chks
I used NodeMcu flasher nodemcu_integer_0.9.5_20150318.bin and NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4. I'm using arduino UART (serial monitor) to talk to ESP8266. BAUD RATE : 115200 FLASH SIZE : 4MB FLASH SPEED : 40MHz SPI : DIO Module is powered with apt power (separate power supply)
Here's my connections:
//////////////////////////////////////////////////////////////////////////////
/////// CONNECTIONS ////////
/////////////////////////////////////////////////////////////////////////////
/*
ESP8266 VCC -> BeagleBone 3.3
ESP8266 GND -> Common GND (Arduino & BeagleBone)
ESP8266 CH_PD -> 3K resistor -> VCC
ESP8266 RST -> VCC or pin 13(arduino)
GPIO CAB BE LEFT OPEN OR TIED HIGH
ESP8266 Tx -> pin2 (Arduino software serial Rx)
ESP8266 Rx <- Voltage Divider <- pin3 (Arduino software serial Tx)
*/
Here's my code
#define esp8266 Serial2
#define CH_PD Vcc // but needs a narrow low pulse
#define speed8266 9600 // This is the speed that worked with my ESP8266
void setup()
{
esp8266.begin (speed8266);
Serial.begin(9600);
reset8266(); // Pin CH_PD need a reset before start communication
}
void loop()
{
while(esp8266.available())
{ Serial.write(esp8266.read()); }
while(Serial.available())
{ esp8266.write(Serial.read()); }
}
/*************************************************/
// Reset funtion to accept communication
void reset8266 ()
{
pinMode(CH_PD, OUTPUT);
digitalWrite(CH_PD, LOW);
delay(300);
digitalWrite(CH_PD, HIGH);
}
Here are some snaps of the configuration i did in NodeMCU ( i had already tried with different baud rates)
Advanced Configuration
Configuration
If you are getting fatal error exception like this:
Exception (3):
epc1=0x401003e9 epc2=0x00000000 epc3=0x00000000 excvaddr=0x4000cbd9 depc=0x00000000
In infinite loop in your serial monitor of arduino IDE .
then goto this link download the software and follow the procedure and erase the flash memory to solve the error.
This does not solve fatal error that occurs due to your program but in case your device goes in such condition that it can’t be able to access program memory then it will work and try atleast one time to solve the problem.
This is the procedure to hard reset the nodemcu
( https://www.youtube.com/watch?v=MHrm7axsImI&t=146s )
Step :
Install latest python version in you pc.(https://www.python.org/downloads )
Open cmd prompt as administrator .
Go to c/program files or program files (x86)->python (your version)->Script. For this type (cd c/program files (x86)/python(your version)/Script) then press enter .
Now type (pip install esptool).
Now download ESPlorer ( https://esp8266.ru/esplorer/ ) version(Download ESPlorer.zip (v 0.2.0-rc6)) and extract the file and open executable jar file .
Now goto nodemcu firmware site (https://github.com/nodemcu/nodemcu-firmware/releases ) and from download file (nodemcu_float_0.9.6-dev_20150704.bin ) and copy this file into the c/program files (x86)/python(your version)/Script folder .
Now in cmd prompt just type.
esptool.py --port COM(your port no.) --baud 115200 erase_flash
And press enter.
Note : you can see your port no. into the device manager .
For NODEMCU users who face this issue
This needs to be done only once (first time you connect nodemcu to PC)
Download and run the 32 or 64 bit flasher*:
32 bit: https://github.com/nodemcu/nodemcu-flasher/blob/master/Win32/Release/ESP8266Flasher.exe
64 bit: https://github.com/nodemcu/nodemcu-flasher/blob/master/Win64/Release/ESP8266Flasher.exe
Select the download button on github and open file once downloaded.
Select the chip port from the previous step (Com 6 for me), and then select flash (this should only have to be done once) close flash program once completed. Process is completed when you get the green checkmark in the bottom left hand corner.
PS: make sure you disconnect and re-connect the nodemcu once done
REFERENCE: https://www.instructables.com/NodeMcu-ESP8266-First-Time-Setup-With-Arduino-IDE/
I'm trying to read a 100gb file through stdin one line at a time using
Port = open_port({fd, 0, 1}, [in, binary, {line, 4096}]),
but this floods my system with messages until I run out of ram. Is there a away to make it like {active, once} with ports? There is also io:get_line() but I was wondering if this could work.
No, there is not flow control over ports so if you can't process fast enough you should use another method of processing. You can set binary mode on STDIN using
ok = io:setopts(standard_io, [binary]),
and then you can read it using file:read_line(standard_io) if you are using version 17 or newer (there was performance impacting bug).