The last post outlined a code change that pinged a watchdog timer periodically so that when the program hung the system would reboot. That has been working well so far.
However, it also allowed the system to be reset/rebooted via a command, which I was unable to do via any previously known method. Simply put, to reset the board, while the /dev/watchdog file is still open, simply delay for more than the timer timeout period (about 60 seconds.) The timer will go off and cause a board reset.
I added a command, sent via a text message, that causes just this timeout and subsequent reset/reboot. So, now I can reset/reboot the board by simply sending that command.
Wednesday, November 21, 2012
Monday, November 5, 2012
Further Bullet Proofing: watchdog timer
Having implemented the previously described circuit and associated code to reset the GSM modem via a USB power cycle when communications with it shut down, there were still occasions when the beaglebone board would lock up, and cease further communications with either the network or the USB-based terminal gadget.
So, I decided that a watchdog timer would provide a last line defense against this sort of "crash." The beaglebone has a special watchdog timer that can be used for just this purpose. When the file /dev/watchdog is open, absence of a write to it for more then about one minute will cause the entire board to reset and reboot.
I added code to beagelgsm.tcl that opened the file just after startup, and then wrote to it once each main loop, which seemed from inspection to provide much more frequent writes than required to keep the watchdog timer from timing out and resetting the board. I added code to measure loop time and log any times greater than about 30 seconds, to get a sense of what the loop times were.
The system is now up and running, as of about 6 PM November 5, 2012.
So, I decided that a watchdog timer would provide a last line defense against this sort of "crash." The beaglebone has a special watchdog timer that can be used for just this purpose. When the file /dev/watchdog is open, absence of a write to it for more then about one minute will cause the entire board to reset and reboot.
I added code to beagelgsm.tcl that opened the file just after startup, and then wrote to it once each main loop, which seemed from inspection to provide much more frequent writes than required to keep the watchdog timer from timing out and resetting the board. I added code to measure loop time and log any times greater than about 30 seconds, to get a sense of what the loop times were.
The system is now up and running, as of about 6 PM November 5, 2012.
Tuesday, August 14, 2012
Beaglebone Analog Input read() results in 4 bytes
After writing some C code to read the analog inputs, it became clear that reading analog inputs via the file system (.../ain1, etc.), the system returns 4 bytes for each read. The bytes are the ASCII characters for the digits 0-9 (values got from 0-4095), and if the reading is less than 4 digits, the byte = \x00 is placed in trailing locations. The \x00 byte is the string terminator for C, and is not present for readings that are 4 digits long. This could explain why channels shift when reading the analog values via Tcl reads: the area the 4-byte value is read into might not have a string terminator.
So, the technique is to read into a buffer of 5 or more bytes, then make sure the 5th byte is a \x00 by either setting the whole area to \x00 first or storing \x00 there after the read, then the C string will be properly terminated.
So, the technique is to read into a buffer of 5 or more bytes, then make sure the 5th byte is a \x00 by either setting the whole area to \x00 first or storing \x00 there after the read, then the C string will be properly terminated.
Friday, August 10, 2012
Recoding Analog and GSM Modem drivers in C
I have referred to problems with the analog inputs shifting channels and GSM modem hangups often in the blog. Since I've been coding in Tcl, I thought that it might be hiding some behavior or data behind its own layer of software. To investigate this I recoded the analog input and GSM modem interface in C language. Since I've done so I've not seen any problems, but then I've only written test programs. I still need to rewrite the bulk of the monitor in C.
I've been off doing other stuff here in New Hampshire and will not be back to this for a week or so. More then hopefully.
I've been off doing other stuff here in New Hampshire and will not be back to this for a week or so. More then hopefully.
Monday, July 23, 2012
Very strange Beaglebone analog input behavior
As mentioned some time ago, the analog channels seem to shift with time. The input connected to channel 3 (ain3) for instance shifts to ain4 after some time (maybe days.) Rebooting the beaglebone seems to restore correct operation. This shifting makes the board analog inputs worthless for reading sensors, due to the unreliability.
I tried various workarounds, and the latest is to read each channel twice in a row, separated by an 'lseek()' on the channel. It works so far.
Here's the code (tcl) for a library with two functions that read 7 analog inputs, returning either raw bits (0-4095) or voltages (0-1.8V):
;# Read 7 analog inputs of beaglebone board and
;# return as either list of 8 decimal values as voltages,
;# or list of raw bit values from 0-4095.
;# Note pin on P9 vs ain* and return list index correspondence:
;#
;# 0 ain1 Not connected to pin
;# 1 ain2 P9-39
;# 2 ain3 P9-40
;# 3 ain4 p9-37
;# 4 ain5 p9-38
;# 5 ain6 p9-33
;# 6 ain7 p9-36
;#...
package provide beagleio 0.1
namespace eval beagleio {
variable initialized 0
variable fds
# Open all analog 'channels' (actually files in Angstrom)
proc init {} {
variable fds
for {set i 1} {$i < 7} {incr i} {
set fds($i) [open /sys/devices/platform/tsc/ain$i r]
}
}
proc beaglearead_v {} {
variable fds
variable initialized
if {$initialized == 0} {
beagleio::init
set initialized 1
}
set vl {}
for {set i 1} {$i < 7} {incr i} {
;# Who the hell knows why we need to do this twice to read the right channel
;# consistently? But we do...
seek $fds($i) 0
set val [read $fds($i)]
seek $fds($i) 0
set val [read $fds($i)]
;#puts "Debug: beaglearead_b: read (length [string length $val]) value $val from channel $i"
;# delete characters = 0x0 ,since these get sent back when analog file is read.
regexp {(\d+)} $val all val
;#puts "Debug: beaglearead_b: modified value (length [string length $val]) is $val from channel $i"
;# Convert to voltages: 0-4095 full scale = 1.8 volts.
lappend vl [format %6.3f [expr 1.8 * $val/4096]]
}
return $vl
}
proc beaglearead_b {} {
variable fds
variable initialized
if {$initialized == 0} {
beagleio::init
set initialized 1
}
set vl {}
for {set i 1} {$i < 7} {incr i} {
# Who the hell knows why we need to do this twice to read the right channel
# consistently? But we do...
seek $fds($i) 0
set val [read $fds($i)]
seek $fds($i) 0
set val [read $fds($i)]
#puts "Debug: beaglearead_b: read (length [string length $val]) value $val from channel $i"
;# delete characters = 0x0 ,since these get sent back when analog file is read.
regexp {(\d+)} $val all value
;#regsub -all {\x000} $val {} val
;#puts "Debug: beaglearead_b: modified value (length [string length $val]) is $val from channel $i"
lappend vl $value
}
return $vl
}
}
I tried various workarounds, and the latest is to read each channel twice in a row, separated by an 'lseek()' on the channel. It works so far.
Here's the code (tcl) for a library with two functions that read 7 analog inputs, returning either raw bits (0-4095) or voltages (0-1.8V):
;# Read 7 analog inputs of beaglebone board and
;# return as either list of 8 decimal values as voltages,
;# or list of raw bit values from 0-4095.
;# Note pin on P9 vs ain* and return list index correspondence:
;#
;# 0 ain1 Not connected to pin
;# 1 ain2 P9-39
;# 2 ain3 P9-40
;# 3 ain4 p9-37
;# 4 ain5 p9-38
;# 5 ain6 p9-33
;# 6 ain7 p9-36
;#...
package provide beagleio 0.1
namespace eval beagleio {
variable initialized 0
variable fds
# Open all analog 'channels' (actually files in Angstrom)
proc init {} {
variable fds
for {set i 1} {$i < 7} {incr i} {
set fds($i) [open /sys/devices/platform/tsc/ain$i r]
}
}
proc beaglearead_v {} {
variable fds
variable initialized
if {$initialized == 0} {
beagleio::init
set initialized 1
}
set vl {}
for {set i 1} {$i < 7} {incr i} {
;# Who the hell knows why we need to do this twice to read the right channel
;# consistently? But we do...
seek $fds($i) 0
set val [read $fds($i)]
seek $fds($i) 0
set val [read $fds($i)]
;#puts "Debug: beaglearead_b: read (length [string length $val]) value $val from channel $i"
;# delete characters = 0x0 ,since these get sent back when analog file is read.
regexp {(\d+)} $val all val
;#puts "Debug: beaglearead_b: modified value (length [string length $val]) is $val from channel $i"
;# Convert to voltages: 0-4095 full scale = 1.8 volts.
lappend vl [format %6.3f [expr 1.8 * $val/4096]]
}
return $vl
}
proc beaglearead_b {} {
variable fds
variable initialized
if {$initialized == 0} {
beagleio::init
set initialized 1
}
set vl {}
for {set i 1} {$i < 7} {incr i} {
# Who the hell knows why we need to do this twice to read the right channel
# consistently? But we do...
seek $fds($i) 0
set val [read $fds($i)]
seek $fds($i) 0
set val [read $fds($i)]
#puts "Debug: beaglearead_b: read (length [string length $val]) value $val from channel $i"
;# delete characters = 0x0 ,since these get sent back when analog file is read.
regexp {(\d+)} $val all value
;#regsub -all {\x000} $val {} val
;#puts "Debug: beaglearead_b: modified value (length [string length $val]) is $val from channel $i"
lappend vl $value
}
return $vl
}
}
Tuesday, July 17, 2012
Connecting to Beaglebone USB Serial port from Ubuntu
Open a Ubuntu termial window, resize it to whatever you want it to be while logged on to the Beaglebone, find the LINES and COLUMNS ($ echo $LINES $COLUMNS) and remember them, then run screen command to get connection to Beaglebone USB serial port:
john@john-ThinkPad-T42:~$ screen /dev/ttyUSB1 115200
.---O---. john@john-ThinkPad-T42:~$ screen /dev/ttyUSB1 115200
| | .-. o o
| | |-----.-----.-----.| | .----..-----.-----.
| | | __ | ---'| '--.| .-'| | |
| | | | | |--- || --'| | | ' | | | |
'---'---'--'--'--. |-----''----''--' '-----'-'-'-'
-' |
'---'
The Angstrom Distribution beaglebone ttyO0
Angstrom v2012.03-core - Kernel 3.2.13
beaglebone login:
After logging on, run the 'stty' command to set lines and columns, like:
$ stty rows 30
$ stty columns 109
When logging on using ssh, if Beaglebone is on the network, the stty commands are unnecessary. BTW, I use and Asus portable wireless access point connected to the Beaglebone ethernet connector to get on the net.
Wednesday, July 4, 2012
Upgrade notes
Problems with reading analog channels consistently made the current system unreliable. So, I tried a new Angstrom drop (dated June 18th, 2012.) That did not work due to GSM modem (/dev/ttyHS*) problems, whereby the system somehow kept doing something to the Icon modem keeping it from registering with AT&T. The new drop was:
Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.06.18.img.xz
So, I decided to just try upgrading the current system. I copied an image of the current working system from the 4GB microSD card to a new card (using linux 'dd if=/dev/sdb of=/dev/sdc', where /dev/sdb is the original microsd card and /dev/sdc is the new fresh card) , then tried doing 'opkg update', 'opkg upgrade' with the new microsd card copy. I moved the new kernel (3.2.14) to the right place as discussed in this blog previously. Then I installed from ipk files tcl, tcllib and modeswitch. Modeswitch install failed due to problems with the names of perl package files, so I added perl package links:
ln -s /var/lib/opkg/info/perl-module-build.list /var/lib/opkg/info/perl-module-build.pm.list
ln -s /var/lib/opkg/info/perl-module-load.list /var/lib/opkg/info/perl-module-load.pm.list
which made the modeswitch opkg install of modeswitch work.
After all that, the analog channel shifting seems to still be a problem. So, on the hunch that a delay was needed between reading channels I added 0.1 seconds in the loop that reads channels. We will see how this turns out.
Later: Badly. Problem still there. Channel 1 is at ain1 at first, then ain2 later. So, on the hunch that the problem had something to do with the files descriptor pointer, I tried doing a 'seek()' to rewind file and that has worked so far.
Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.06.18.img.xz
So, I decided to just try upgrading the current system. I copied an image of the current working system from the 4GB microSD card to a new card (using linux 'dd if=/dev/sdb of=/dev/sdc', where /dev/sdb is the original microsd card and /dev/sdc is the new fresh card) , then tried doing 'opkg update', 'opkg upgrade' with the new microsd card copy. I moved the new kernel (3.2.14) to the right place as discussed in this blog previously. Then I installed from ipk files tcl, tcllib and modeswitch. Modeswitch install failed due to problems with the names of perl package files, so I added perl package links:
ln -s /var/lib/opkg/info/perl-module-build.list /var/lib/opkg/info/perl-module-build.pm.list
ln -s /var/lib/opkg/info/perl-module-load.list /var/lib/opkg/info/perl-module-load.pm.list
which made the modeswitch opkg install of modeswitch work.
After all that, the analog channel shifting seems to still be a problem. So, on the hunch that a delay was needed between reading channels I added 0.1 seconds in the loop that reads channels. We will see how this turns out.
Later: Badly. Problem still there. Channel 1 is at ain1 at first, then ain2 later. So, on the hunch that the problem had something to do with the files descriptor pointer, I tried doing a 'seek()' to rewind file and that has worked so far.
Wednesday, June 6, 2012
Why am I bothering to Blog this?
I sometimes ask myself this question, since there are few readers other than myself, and writing it takes some energy. Is it wasted? The answer no. It's a way of documenting what I've done for my own future reference, and at the same time makes it possible for others to comment or add to the conversation and/or design. I really believe in documenting stuff so I can go back and reproduce what I've done. I could write this in a google document, but a web log is really easier, since it date stamps stuff, and makes it public at the same time. I've nothing to sell, so don't expect to see fancy writing promoting a product here.
Hope that helps fill in the background.
Hope that helps fill in the background.
Still running after all these days
I haven't actually done anything with the Beaglebone monitor, except to start laying out a PC board to contain the relatively simple circuitry that feeds two NTC thermistors, a powerline indicator, and a switch to allow the program via a GPIO bit to connect and disconnect the Icon modem from the USB bus to circumvent software/hardware modem problems.
The system is still running and tweeting status. Follow @zouckhome to see what it's sending. It has not restarted due to a timeout in 7 days. I'm sort fo looking forward to when it times out and restarts so I can see if that still works.
The system is still running and tweeting status. Follow @zouckhome to see what it's sending. It has not restarted due to a timeout in 7 days. I'm sort fo looking forward to when it times out and restarts so I can see if that still works.
Tuesday, May 29, 2012
Beaglebone Support Board Schematic using ExpressSCH
The USB power switch also uses a separate power supply for the modem, so it acts sort of like a powered hub, and has plenty of power. (Limited power is a chief suspect in a previously reported problem where the modem would stop working very frequently.)
I actually have this stuff wired up on a couple of breadboards, mounted with the Beaglebone on a piece of foam. Might see about making a PC board (shield or whatever Beaglebone people call the boards that mate with the Beaglebone external expansion connectors.)
I published an informal hand-drawn schematic in the last post here. This is a better schematic of the support circuitry that does this:
Monday, May 28, 2012
Beaglebone Start-up Script, with GSM modem reconnect
This script is run via cron using the @reboot time. It handles unplugging and replugging the modem, and restarting the 'tclsh beagelgsm.tcl' script command when it exits.
#!/bin/sh
#
# beaglegsm.sh - SHell script to run beaglegsm.tcl from
# cron job.
#
# This script is meant to run 'tclsh beaglegsm.tcl' on a Beaglebone
# board, using an Option Icon 322 USB modem, connected to a UAB port with
# a special cable and circuit that allows a program to disconnect and reconnect the modem
# using the Beaglebone GPIO bit on pin 3 of the P8 expansion connector to disconnect and
# reconnect +5V USB power to the modem via the USB cable. The GPIO bit is named gpio1_6
# in the P8 connector pinout table in the Beaglebone System Reference Manual (A5).
#
# The need to disconnect and reconnect is due to some obscure bug that ocassionally
# makes the modem time-out during operations in the TCL script beaglegsm.tcl. It seems
# that the disconnect/reconnect is needed to reset the modem.
# We assume the gpio pin multiplexer is set up for pin 3 of P8
# to be a gpio bit (mode 7). This state seems to be maintained after power-down
# and rebooting.
#
# Check this using:
#
# root@beaglebone:~/work# cat /sys/kernel/debug/omap_mux/gpmc_ad6
# name: gpmc_ad6.gpio1_6 (0x44e10818/0x818 = 0x0037), b NA, t NA
# mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
# signals: gpmc_ad6 | mmc1_dat6 | NA | NA | NA | NA | NA | gpio1_6
# Export bit and set direction to out.
function setupgpio {
# Export gpio1_6 so we can manipulate it
# (38 = 1 * 32 + 6)
echo 38 > /sys/class/gpio/export
echo out >/sys/class/gpio/gpio38/direction
}
# Set gpio1_6 so that USB cuts power to modem
function cut_usbpower {
echo 1 >/sys/class/gpio/gpio38/value
}
# Set gpio1_6 so that USB supplies power to the modem.
function apply_usbpower {
echo 0 >/sys/class/gpio/gpio38/value
}
cd /home/root/tcl-from-beaglebone/tcl/
setupgpio
apply_usbpower
sleep 15
while [ true ]; do
echo "(`date`) Running beaglegsm.tcl"
tclsh beaglegsm.tcl &>beaglegsm-tclsh.out
echo "Beaglegsm.tcl exited. Resetting modem and restarting"
cut_usbpower
sleep 20
apply_usbpower
sleep 30
done
#
# beaglegsm.sh - SHell script to run beaglegsm.tcl from
# cron job.
#
# This script is meant to run 'tclsh beaglegsm.tcl' on a Beaglebone
# board, using an Option Icon 322 USB modem, connected to a UAB port with
# a special cable and circuit that allows a program to disconnect and reconnect the modem
# using the Beaglebone GPIO bit on pin 3 of the P8 expansion connector to disconnect and
# reconnect +5V USB power to the modem via the USB cable. The GPIO bit is named gpio1_6
# in the P8 connector pinout table in the Beaglebone System Reference Manual (A5).
#
# The need to disconnect and reconnect is due to some obscure bug that ocassionally
# makes the modem time-out during operations in the TCL script beaglegsm.tcl. It seems
# that the disconnect/reconnect is needed to reset the modem.
# We assume the gpio pin multiplexer is set up for pin 3 of P8
# to be a gpio bit (mode 7). This state seems to be maintained after power-down
# and rebooting.
#
# Check this using:
#
# root@beaglebone:~/work# cat /sys/kernel/debug/omap_mux/gpmc_ad6
# name: gpmc_ad6.gpio1_6 (0x44e10818/0x818 = 0x0037), b NA, t NA
# mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
# signals: gpmc_ad6 | mmc1_dat6 | NA | NA | NA | NA | NA | gpio1_6
# Export bit and set direction to out.
function setupgpio {
# Export gpio1_6 so we can manipulate it
# (38 = 1 * 32 + 6)
echo 38 > /sys/class/gpio/export
echo out >/sys/class/gpio/gpio38/direction
}
# Set gpio1_6 so that USB cuts power to modem
function cut_usbpower {
echo 1 >/sys/class/gpio/gpio38/value
}
# Set gpio1_6 so that USB supplies power to the modem.
function apply_usbpower {
echo 0 >/sys/class/gpio/gpio38/value
}
cd /home/root/tcl-from-beaglebone/tcl/
setupgpio
apply_usbpower
sleep 15
while [ true ]; do
echo "(`date`) Running beaglegsm.tcl"
tclsh beaglegsm.tcl &>beaglegsm-tclsh.out
echo "Beaglegsm.tcl exited. Resetting modem and restarting"
cut_usbpower
sleep 20
apply_usbpower
sleep 30
done
Rough Hand-drawn Schematic
Here's a rough schematic of my home monitor setup. The Beaglebone is the box in the middle.
At the top is the isolated USB power switch to simulate unplugging and replugging the GSM modem. A relay is used to switch power, with the normally closed contacts used, so that power is not consumed by the relay (100 ma current draw) except in the short time the relay is actuated to remove power from the modem.
At the bottom is the basic sensor circuit. Two 10K NTC thermistors measure temperature, and with the accompanying 10 K resistors result in a variable voltage fed into AIN0 and AIN1 on the Beagleboard. A/C power presence is detected by the 'wall wart' on the left, feeding an isolator (the PS2501 quad opto isolator), which feeds AIN2 on the Beagleboard. It does not attempt to measure A/C voltage, but just determines if there is any. I was lazy when I designed it and had not figured out how to configure and read gpio bits yet, so I solved it by just measuring voltage.
At the top is the isolated USB power switch to simulate unplugging and replugging the GSM modem. A relay is used to switch power, with the normally closed contacts used, so that power is not consumed by the relay (100 ma current draw) except in the short time the relay is actuated to remove power from the modem.
At the bottom is the basic sensor circuit. Two 10K NTC thermistors measure temperature, and with the accompanying 10 K resistors result in a variable voltage fed into AIN0 and AIN1 on the Beagleboard. A/C power presence is detected by the 'wall wart' on the left, feeding an isolator (the PS2501 quad opto isolator), which feeds AIN2 on the Beagleboard. It does not attempt to measure A/C voltage, but just determines if there is any. I was lazy when I designed it and had not figured out how to configure and read gpio bits yet, so I solved it by just measuring voltage.
Sunday, May 27, 2012
The Strange World of Beaglebone GPIO
In the last post I mentioned that I was going to investigate a workaround for the problem of a non-responsive GSM modem, based on unplugging, then replugging it in, simulated by switching the +5V USB line connected to pin 1 of the USN connector. I modified a USB cable, breaking the red +5V line, and connecting and disconnecting it to simulate plugging and unplugging the GSM mode.
The results were as expected: when disconnected, the software disabled the ttyHS* ports, and reconnecting the line caused the software to reestablish them. This demonstrated we can reset the modem under program control. All that remains is to design a circuit that switched the +5V USB line under program control, using spare GPIO bits. And, of course writing software to sense when the modem is misbehaving, and toggle the +5V control bit to simulate the unplug/plug operation.
As many people have noted, managing the GPIO bits is a little complicated. Nathan Dumont has provided a good overview of the process in his blog. I followed his general instructions and wanted to quickly record what I did here. These are some commands entered from the bash command line to control gpio1_7, which is on pin 4 of expansion connector P8. The name format gpiox_y is how the system codes bit y of gpio bank x.
Check that the multiplexer has gpio1_7 (which is called gpmc_ad7 in the mux directory and tables) set for mode7, which is a GPIO bit:
root@beaglebone:~/work# cat /sys/kernel/debug/omap_mux/gpmc_ad7
name: gpmc_ad7.gpio1_7 (0x44e1081c/0x81c = 0x0007), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | gpio1_7
It's set right, so no need to change it.
Now, to be able to control the pin we need to write the number representing the gpio bit, computed by taking the gpio bank (1), multiplying by 32 (bits per bank) and adding the bit number (7), giving 2*32+7 = 39, to the export 'file' in /sys/class/gpio:
root@beaglebone:~/work# echo 39 > /sys/class/gpio/export'
We want to use it as an output, so write 'out' to the 'file /sys/class/gpio/gpio39/direction:
Set the bit to 1:
root@beaglebone:~/work# echo 1 >/sys/class/gpio/gpio39/value
Then 0:
root@beaglebone:~/work# echo 0 >/sys/class/gpio/gpio39/value
And when done, unexport so other programs can use it:
root@beaglebone:~/work# echo 39 > /sys/class/gpio/unexport
The results were as expected: when disconnected, the software disabled the ttyHS* ports, and reconnecting the line caused the software to reestablish them. This demonstrated we can reset the modem under program control. All that remains is to design a circuit that switched the +5V USB line under program control, using spare GPIO bits. And, of course writing software to sense when the modem is misbehaving, and toggle the +5V control bit to simulate the unplug/plug operation.
As many people have noted, managing the GPIO bits is a little complicated. Nathan Dumont has provided a good overview of the process in his blog. I followed his general instructions and wanted to quickly record what I did here. These are some commands entered from the bash command line to control gpio1_7, which is on pin 4 of expansion connector P8. The name format gpiox_y is how the system codes bit y of gpio bank x.
Check that the multiplexer has gpio1_7 (which is called gpmc_ad7 in the mux directory and tables) set for mode7, which is a GPIO bit:
root@beaglebone:~/work# cat /sys/kernel/debug/omap_mux/gpmc_ad7
name: gpmc_ad7.gpio1_7 (0x44e1081c/0x81c = 0x0007), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | gpio1_7
It's set right, so no need to change it.
Now, to be able to control the pin we need to write the number representing the gpio bit, computed by taking the gpio bank (1), multiplying by 32 (bits per bank) and adding the bit number (7), giving 2*32+7 = 39, to the export 'file' in /sys/class/gpio:
root@beaglebone:~/work# echo 39 > /sys/class/gpio/export'
We want to use it as an output, so write 'out' to the 'file /sys/class/gpio/gpio39/direction:
root@beaglebone:~/work# echo out >/sys/class/gpio/gpio39/direction
Set the bit to 1:
root@beaglebone:~/work# echo 1 >/sys/class/gpio/gpio39/value
Then 0:
root@beaglebone:~/work# echo 0 >/sys/class/gpio/gpio39/value
And when done, unexport so other programs can use it:
root@beaglebone:~/work# echo 39 > /sys/class/gpio/unexport
Thursday, May 24, 2012
Bullet-proofing the Monitor Software
There have been a number of issues regarding the Icon GSM/GPRS USB modem in the home monitor. The main two are (1) that it does not get recognized and switched to serial-port mode on power-up boot (but does on subsequent command line reboots) and (2) that it sometimes (but rarely) stops responding to sending AT commands, and must be unplugged and plugged in again (or the system must be rebooted.)
I believe I can solve both problems without having to physically unplug and replug in the modem, which is impossible when I'm away. A software way to do this eludes me at this time, and I'm running out of time, so I will try a partly hardware way to do this: by disconnecting the USB 5V power line to the modem and reconnecting it. I will use an output bit (GPIO) on the Beaglebone to switch the 5V under program control.
The idea is to set the bit set by default so as not to supply power to the modem on reboot, or initial boot up. Then, later, when I run the monitor program I will set the bit to supply power to the modem and wait for the five devices /dev/ttyHS0-4 to appear in the file system. If this is like plugging in the modem, I should see the /dev/ttyHS0-4 devices in the file system, after the usb-modeswitch software recognizes the modem and >switches it to the serial port USB device, creating the five devices.
Here is an outline of the program at startup:
- Switch power to the GSM USB modem off, then on with a 30 second delay using the GPIO bit that controls modem USB power.
- Wait until the five /dev/ttyHS* devices appear in the file system.
- Open the modem as usual and test it by issuing a plain 'AT' command.
- If either of these steps do not work, go back to step 1.
For reference, here is the pin-out for the USB cable:
| Pin | Name | Cable color | Description |
|---|---|---|---|
| 1 | VCC | Red | +5 VDC |
| 2 | D- | White | Data - |
| 3 | D+ | Green | Data + |
| 4 | GND | Black | Ground |
Notes on Setting up Console Screen Size using 'stty'
Using PuTTY to open a console to the USB slave port on the Beaglebone (say COM20 on Windows 7), you specify to PuTTY the screen size you want, say 100 columns by 40 rows, before opening the console. Then, when logged in to the Beaglebone shell via the console, to make things like 'vi' and 'less' work right, you need to issue the stty commands:
$ stty columns 100
$ stty rows 40
Then screen-size sensitive programs like 'vi' and 'less' will work right. After resizing the screen console window (say, by dragging corners of the windows), the programs will not work correctly again until the stty commands are given with the new sizes.
$ stty columns 100
$ stty rows 40
Then screen-size sensitive programs like 'vi' and 'less' will work right. After resizing the screen console window (say, by dragging corners of the windows), the programs will not work correctly again until the stty commands are given with the new sizes.
Thursday, May 17, 2012
Using cron to Start Monitor Program at Boot Time
The idea is to run the tcl program beaglegsm.tcl at boot time, using tclsh of course. To do this edit the root cron entries using the 'crontab -e' command. The crontab entries for root are as follows. Note the complete path entries for program script and log files.
File beaglegsm.sh:
#!/bin/sh
cd /home/root/tcl-from-beaglebone/tcl/
sleep 120
while [ true ]; do
echo "(`date`) Running beaglegsm.tcl"
tclsh beaglegsm.tcl &>beaglegsm-tclsh.out
insmod /lib/modules/3.2.13/kernel/drivers/net/usb/hso.ko
echo "Beaglegsm.tcl exited. Delaying then restarting"
sleep 120
done
The 120 second delay is to let the modem power up and be recognized by Linux as /dev/ttyHS0-3. If the program faults (due lately to the modem somehow timing out), the insmod tries to re-establish the /dev/ttyHS- device, but this feature is experimental and will likely go away soon.
When power is disconnected and comes back up, the modem seems not to be recognized correctly. But, after a reboot command it seems to be recognized OK. I may add a reboot text message to reboot, and also have the unit do a reboot automatically when the modem is not recognized.
Since the beaglebone is off the network, ntp will not set the time, and since it has no clock, time will default to something like 'Fri Apr 13 16:43:26 EDT 2012'. I will try to fix this by having the unit set time on ceceipt of the first text message, getting the time from the date message field.
30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org
@reboot /home/root/tcl-from-beaglebone/tcl/beaglegsm.sh >/home/root/tcl-\
@reboot /home/root/tcl-from-beaglebone/tcl/beaglegsm.sh >/home/root/tcl-\
from-beaglebone/tcl/cronout.log
File beaglegsm.sh:
#!/bin/sh
cd /home/root/tcl-from-beaglebone/tcl/
sleep 120
while [ true ]; do
echo "(`date`) Running beaglegsm.tcl"
tclsh beaglegsm.tcl &>beaglegsm-tclsh.out
insmod /lib/modules/3.2.13/kernel/drivers/net/usb/hso.ko
echo "Beaglegsm.tcl exited. Delaying then restarting"
sleep 120
done
The 120 second delay is to let the modem power up and be recognized by Linux as /dev/ttyHS0-3. If the program faults (due lately to the modem somehow timing out), the insmod tries to re-establish the /dev/ttyHS- device, but this feature is experimental and will likely go away soon.
When power is disconnected and comes back up, the modem seems not to be recognized correctly. But, after a reboot command it seems to be recognized OK. I may add a reboot text message to reboot, and also have the unit do a reboot automatically when the modem is not recognized.
Since the beaglebone is off the network, ntp will not set the time, and since it has no clock, time will default to something like 'Fri Apr 13 16:43:26 EDT 2012'. I will try to fix this by having the unit set time on ceceipt of the first text message, getting the time from the date message field.
Sunday, April 22, 2012
Icon USB GSM Modem Driver Startup Problems
Sometimes when rebooted Angstrom does not create the GSM modem devices /dev/ttyHS0-3. By removing the USB modem and reinserting it it seems to work, but we can't always do this, as when power fails and comes back up and we aren't there.
The device can also be created by inserting the module hso.ko into the kernel explicitly:
This can be tested by removing it first with 'rmmod hso'.
I will place the insmod command in the crontab shell script that starts the monitor tclsh program and see what happens.
....
Later: That did not work reliably (the ttyHS0-3 did not get created unless I unplugged the modem and plugged it in again.)
So to investigate what's happening on reboot, I went to the web site http://www.draisberghof.de/usb_modeswitch/ and turned on logging in the config file /etc/usb_modeswitch.conf. This should place log statements in the file /var/log/usb_modeswitch_<interface name>. We will see.
...
Later: logging only happens when hot plugging modem, not at boot time, and usb modeswitch seems to work when hot plugging. How does the usb modeswitch command work at boot time? Do I have to add a delay and manually call usb modeswitch?
The device can also be created by inserting the module hso.ko into the kernel explicitly:
# insmod /lib/modules/3.2.13/kernel/drivers/net/usb/hso.ko
This can be tested by removing it first with 'rmmod hso'.
I will place the insmod command in the crontab shell script that starts the monitor tclsh program and see what happens.
....
Later: That did not work reliably (the ttyHS0-3 did not get created unless I unplugged the modem and plugged it in again.)
So to investigate what's happening on reboot, I went to the web site http://www.draisberghof.de/usb_modeswitch/ and turned on logging in the config file /etc/usb_modeswitch.conf. This should place log statements in the file /var/log/usb_modeswitch_<interface name>. We will see.
...
Later: logging only happens when hot plugging modem, not at boot time, and usb modeswitch seems to work when hot plugging. How does the usb modeswitch command work at boot time? Do I have to add a delay and manually call usb modeswitch?
Thursday, April 19, 2012
Beaglebone GSM modem program endurance test
This is a quick update. I've been running the home monitor program for around a week on the Beaglebone embedded Linux (Angstrom) system, with the Option Icon modem connected via a powered USB hub, and the board entirely on its own. "On its own" means not connected to the network or the host USB bus on the PC, so it cannot communicate other than via SMS (text) messaging. It has not stopped by itself yet, so it appears very likely that the USB power was an issue in earlier failures.
It starts automatically on reboot (power cycling.) I have set a crontab job (shell script) scheduled for @reboot, that runs the tclsh interpreter on my monitor program after an initial 120 second delay after reboot to let the GSM modem be recognized by the OS.
In testing, I have temporarily interrupted power to both the powered hub and board to make sure it restarts OK, and no problems yet. This is important since if I'm away and it fails I can simply have someone cycle power to get it going. Also, I can build a simple external "keep-alive" circuit the monitor program must periodically 'ping' with a GPIO bit level change. In the absence of the pulse the circuit will cause power to be recycled via maybe a relay (optically isolated, naturally.)
Of course Beaglebone also cannot set its clock since it has no internal battery-backed clock, so I'll have to figure out a way of doing this. Maybe by having it send itself a text message, and getting the time from the received message.
It starts automatically on reboot (power cycling.) I have set a crontab job (shell script) scheduled for @reboot, that runs the tclsh interpreter on my monitor program after an initial 120 second delay after reboot to let the GSM modem be recognized by the OS.
In testing, I have temporarily interrupted power to both the powered hub and board to make sure it restarts OK, and no problems yet. This is important since if I'm away and it fails I can simply have someone cycle power to get it going. Also, I can build a simple external "keep-alive" circuit the monitor program must periodically 'ping' with a GPIO bit level change. In the absence of the pulse the circuit will cause power to be recycled via maybe a relay (optically isolated, naturally.)
Of course Beaglebone also cannot set its clock since it has no internal battery-backed clock, so I'll have to figure out a way of doing this. Maybe by having it send itself a text message, and getting the time from the received message.
Monday, April 9, 2012
Google Document with Beaglebone notes
Before I started this blog, I wrote some detailed notes as I brought up the Beaglebone. They are in the form of a Google document. I hope to keep further notes in this blog, but I wanted to mention it here to keep from having to copy this document into this blog.
Underpowered USB port may have caused the GSM Modem dropout
I suspected that the Option Icon 322 GSM modem dropout (timeout on 'at' commands) may have been due to USB power supply capabilities. So, as a test I have been running the GSM modem with the Beaglebone Linux board, but attached to a powered USB hub instead of directly attached to the host USB port on the Beagleone. My simple program that reports temperatures and power status has been running without a hitch for more than a day now, so it is looking likely that this is the problem. I'll let it run overnight as a further check before enabling the full range of monitor capabilities, which include replying to SMS senders instead of simply tweeting the SMS and running commands sent in the SMS text.
Friday, April 6, 2012
Upgrade summary
I will summarize my experience upgrading my beaglebone angstrom system from the A5 version to the hopefully latest. It was painful and may not have solved any problems. Here are the steps:
1. Did an 'opkg update', followed by an 'opkg upgrade'.
This failed with the previously mentioned perl problems:
1. Did an 'opkg update', followed by an 'opkg upgrade'.
This failed with the previously mentioned perl problems:
Collected errors:
* pkg_get_installed_files: Failed to open //var/lib/opkg/info/perl-
* pkg_get_installed_files: Failed to open //var/lib/opkg/info/perl-
Fixed this using the solutions found on this page.
Did another update/upgrade sequence which seemed to work.
2. Moved the new kernel 3.2.13 to the boot partition of the microSD card, since this is required to use it on booting (see gigamegablog.)
3. Rebooted, and did an 'ifup eth0' from a logon via the usb console connection to get the ethernet running.
4. Re-installed the usb-modeswitch-data_20120120-r0_all.ipk and usb-modeswitch_1.2.2-r0_armv7a.ipk packages to get the gsm modem running.
Other angstrom upgrade bugs/fixes
Upgrades (opkg upgrade) fail after updating (opkg update), and the following link has essential steps to correct the issue:
https://groups.google.com/forum/?fromgroups#!msg/beagleboard/4PDEnRXy7aA/jezLduIk90cJ
In essence file names need to be changed in several places via links and edits. This indicates beaglebone angstrom is in a state of extreme flux at this time.
https://groups.google.com/forum/?fromgroups#!msg/beagleboard/4PDEnRXy7aA/jezLduIk90cJ
In essence file names need to be changed in several places via links and edits. This indicates beaglebone angstrom is in a state of extreme flux at this time.
Make sure to move kernel to boot partition after upgrade
To boot with the latest kernel, be sure to follow directions on the gigamegablog, quoted here, to boot using it:
When opkg delivers the kernels, it doesn’t install them. To start using a new kernel, you need to manually install it onto the boot partition of the SD card – you can easily do this right from the Beaglebone command prompt.
Begin by mounting the boot partition. You need to use a directory as a mount point: I’m using one called tmp:
When opkg delivers the kernels, it doesn’t install them. To start using a new kernel, you need to manually install it onto the boot partition of the SD card – you can easily do this right from the Beaglebone command prompt.
Begin by mounting the boot partition. You need to use a directory as a mount point: I’m using one called tmp:
root:~# mkdir tmp root:~# mount /dev/mmcblk0p1 tmp
If you look at the mount point, you should see the following files:
root:~# ls tmp Docs LICENSE.txt README.htm u-boot.img uImage Drivers MLO autorun.inf info.txt uEnv.txt
Overwrite the uImage with the latest kernel file from /boot:
root:~# cp /boot/uImage-3.2.9+ tmp/uImage
Unmount to make sure everything is nicely tucked away on the SD card, then reboot:
root:~# umount tmp root:~# shutdown -r now
Wednesday, March 28, 2012
Modem fails to respond at long intervals
The Option Icon 322 USB modem fails to respond to at commands at long intervals, and causes timeouts when waiting for a response to an at command, which are detected using the 'catch' command and causing my program to exit. When this happens, stopping and restarting the program does no good. The second restart always fails at the open() call, and by using 'fuser' ('fuser /dev/ttyHS0) it appears that the program has opened the modem, but gets stuck at a tcsetattr() call, according to the stack trace when I attach 'gdb' to the process. But, running minicom seems to restore correct operation. What does minicom do that the program does not do? If I can find out I can at least restart the program successfully. I would of course like to be able to reset the modem to restore it, but I can't figure out what does that, other than somehow (modprobe -r) deactivating the usbserial module and reactivating it.
To find out I ran both ('tclsh beaglegsm.tcl' and minicom) using 'strace' to trace system calls. Except for the open call, both do the same things regarding protocol in sending 'at' commands. The open call for minicom uses the switches:
open("/dev/ttyHS0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
while beaglegsm.tcl uses:
open /dev/ttyHS0 RDWR
I programmed the open in tcl to use these same flags as minicom, and I'm now testing this arrangement:
open /dev/ttyHS0 {RDWR NOCTTY NONBLOCK}
To find out I ran both ('tclsh beaglegsm.tcl' and minicom) using 'strace' to trace system calls. Except for the open call, both do the same things regarding protocol in sending 'at' commands. The open call for minicom uses the switches:
open("/dev/ttyHS0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
while beaglegsm.tcl uses:
open /dev/ttyHS0 RDWR
I programmed the open in tcl to use these same flags as minicom, and I'm now testing this arrangement:
open /dev/ttyHS0 {RDWR NOCTTY NONBLOCK}
Wednesday, March 21, 2012
Starting my Program as a Daemon
As an interim test, to run a monitor program as a daemon so I can log off and disconnect the Beaglebone from the net without killing the program, I used the start-stop-daemon command as follows:
root@beaglebone:~/tcl-from-beaglebone/tcl# start-stop-daemon -S -b \
-x /usr/bin/tclsh -- beaglegsm.tcl
The program is a Tcl script, beaglegsm.tcl, in a subdirectory of root. I give the full path to the tclsh command, but only the relative path to the script. The -b switch runs the program in the background. The -S switch says start the program. It seems to know whether one is already running and does not start a new one if so.
To stop the daemon use the -K switch:
root@beaglebone:~/tcl-from-beaglebone/tcl# start-stop-daemon -S -b \
-x /usr/bin/tclsh -- beaglegsm.tcl
So I can start the daemn at boot time so it runs without needing to log on, I'll either put it in a cron entry (use @bootup for the time specification) or as a script in the /etc/init.d directory.
The program quits sometimes, without complaining, so I added a &>beaglegsm.out to the end to try and capture stdout and stderr for later analysis.
root@beaglebone:~/tcl-from-beaglebone/tcl# start-stop-daemon -S -b \
-x /usr/bin/tclsh -- beaglegsm.tcl
The program is a Tcl script, beaglegsm.tcl, in a subdirectory of root. I give the full path to the tclsh command, but only the relative path to the script. The -b switch runs the program in the background. The -S switch says start the program. It seems to know whether one is already running and does not start a new one if so.
To stop the daemon use the -K switch:
root@beaglebone:~/tcl-from-beaglebone/tcl# start-stop-daemon -S -b \
-x /usr/bin/tclsh -- beaglegsm.tcl
So I can start the daemn at boot time so it runs without needing to log on, I'll either put it in a cron entry (use @bootup for the time specification) or as a script in the /etc/init.d directory.
The program quits sometimes, without complaining, so I added a &>beaglegsm.out to the end to try and capture stdout and stderr for later analysis.
Terminal (sh) Sessions on Beaglebone from PC
Here are two ways to get a terminal shell (sh) session going on the Beaglebone board.without using the USB-based serial interface.
Ethernet or Network Via USB
If you don't have a spare ethernet port on a router, you can establish a network connection between the Beaglebone and a PC using a network simulator over a USB connection.
Simply plug the beaglebone in to the PC using the USB cable using the USB client (mini USB connector on the board.) Let it boot up. It will appear as a mass storage device on the PC. The network interface will automatically be established after unmounting (ejecting) this Beagleboard mass storage device under Windows.
Method 1: This is fast
From Linux use ‘ssh root@192.168.7.2’
Password is not set, so just hit enter when asked. Here’s an example:
john@john-ThinkPad-T42:~$ ssh root@192.168.7.2
root@192.168.7.2's password:
root@beaglebone:~#
From Windows, use the PuTTY client.
Method 2: This is very slow.
Using Gate One server on board, accessed from web browser as url 192.168.7.2, at https://192.168.7.2/, at prompt enter 192.168.7.2. Then hit enter at ‘port 22’ question, then enter ‘root’ at user question. You should get a normal terminal session prompt.
Ethernet or Network Via USB
If you don't have a spare ethernet port on a router, you can establish a network connection between the Beaglebone and a PC using a network simulator over a USB connection.
Simply plug the beaglebone in to the PC using the USB cable using the USB client (mini USB connector on the board.) Let it boot up. It will appear as a mass storage device on the PC. The network interface will automatically be established after unmounting (ejecting) this Beagleboard mass storage device under Windows.
Method 1: This is fast
From Linux use ‘ssh root@192.168.7.2’
Password is not set, so just hit enter when asked. Here’s an example:
john@john-ThinkPad-T42:~$ ssh root@192.168.7.2
root@192.168.7.2's password:
root@beaglebone:~#
From Windows, use the PuTTY client.
Method 2: This is very slow.
Using Gate One server on board, accessed from web browser as url 192.168.7.2, at https://192.168.7.2/, at prompt enter 192.168.7.2. Then hit enter at ‘port 22’ question, then enter ‘root’ at user question. You should get a normal terminal session prompt.
Beaglebone Cost and Source
The board I received is marked “A5”, and the microSD card with the software is dated 2-14-2012. Cost was around $89 from Digi-Key. Came with USB data and power cables, microSD card with software, Altoids box.
What this is About
I bought a Beaglebone embedded Linux single board computer for use with my SMS-based home monitor, which has its own blog. That monitor originally used a combination of an ancient Asus netbook and an Arduino single board computer, along with an Option Icon 322 GPRS GSM modem. I hope by using the Beaglebone for both these functions I can reduce power and cost, while increasing reliability.
Here's a picture of a Beaglebone from the website:
The home monitor was designed to communicate strictly using text (SMS) messages, so it is useful where there is no internet service, and low-cost if used with large quantity text message plans, such as the AT&T 1000 messages for $10/month. Since it can send and receive text messages, it can tweet (which it currently does), and can reply to emails with commands to set up monitor functionality, such as reporting period and alarm actions, as well as turn on and off external appliances.
This blog is where I'll log my experiences with the Beaglebone.
Here's a picture of a Beaglebone from the website:
The home monitor was designed to communicate strictly using text (SMS) messages, so it is useful where there is no internet service, and low-cost if used with large quantity text message plans, such as the AT&T 1000 messages for $10/month. Since it can send and receive text messages, it can tweet (which it currently does), and can reply to emails with commands to set up monitor functionality, such as reporting period and alarm actions, as well as turn on and off external appliances.
This blog is where I'll log my experiences with the Beaglebone.
Subscribe to:
Posts (Atom)