| BeagleBone Black | |
|---|---|
 | |
| Owner | User:zmatt |
| Status | Seeking purpose |
| Hostname | bbb |
| Tool | |
| Tool category | |
Bbb-zmattified.jpg {{{InventoryOwner}}}Property "Tool Owner" (as page type) with input value "{{{InventoryOwner}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. {{{Location}}}Property "Tool Location" (as page type) with input value "{{{Location}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Description
BeagleBone Black (rev C), donated by my employer [Dutch & Dutch]. It has one minor defect: one I/O pin (P9.26 / GPIO 0.14) has been damaged, probably by overvoltage, and has become unusable. I've stuffed it with polycaprolactone to clearly mark it and avoid accidental use.
Like most of our BBBs it also has a small patch: the separate regulator for "VDD_3V3B" has been removed and the voltage rail has been tied to the "VDD_3V3A" instead, which means it has a single unified 3.3V rail. This patch was done to avoid the problem where the 3V3B remains enabled too long during poweroff and indefinitely if the BBB is supplied via battery power. With this patch the BBB can be safely powered via its battery terminals (Li-ion/LiPo, BBB has integrated charger). An obvious side-effect is that less power can be drawn from the BBB's 3.3V supply by external hardware. See here for more info on BBB power supply infrastructure.
Information on pin functions can be found in this spreadsheet. Laminated printouts of the P9 and P8 tabs are somewhere in the space in cha0z97's drawer, along with some other documentation. (For proper orientation, have the Ethernet connector facing up. P9 is then the connector on the left and P8 is on the right.)
Hardware safety notes
The expansion header pins connect to the processor without any real protection, and being careless can destroy an IO or the entire processor.
The digital I/Os are 3.3V and are NOT 5V-tolerant.
The analog inputs are max 1.8V. Due to a hardware erratum they may be briefly shorted together and/or to vdd or ground during power-up, hence it is recommended to avoid connecting them to low-impedance outputs (e.g. opamps) without a series resistor.
Avoid injecting current into IOs when the beaglebone is powered off. In particular, the digital I/Os are NOT 3.3V-tolerant when the 3.3V supply is off.
Some pins on the expansion header are used by the on-board eMMC, and must not be touched. On the expansion header overview printouts they are clearly marked "eMMC". If you really need them for other purposes this is still possible, but it requires booting via other means (e.g. μSD or netboot) and disabling the eMMC. Ask me (zmatt) for details if you ever need them.
The last 16 pins of header P8 are sampled at power-on to determine boot configuration. They have weak (100KΩ) on-board pull up/down resistors. They can be freely used afterwards, but be careful not to meddle with them during power-on unless altering the boot config is intended. They are not resampled at reset, only at power-on.
Playing with it
Battery pack has been attached, can be charged via USB or the 5V DC barrel jack (1A or more recommended, but less should work too). Use script mentioned below to check its status. The battery will not last as long as you'd expect it to since there is no boost conversion and the system will shut off when the 3.3V supplies lose regulation. Since the pack is quite big it can still run for many hours though. Running on battery power will render the USB host and device ports inoperable due to invalid VBUS level. Instead of an actual temperature sensor there's a resistor on the battery header telling the charger the temperature is okay for charging. Be careful not to use this setup outside the safe temperature range for charging the battery pack (0 - 45 ͏°C).
The bbb has been flashed via USB with jessie-8.3-iot-2016-03-27. Latest images can be found here. I personally normally start with a "console" image, which is extremely minimalistic and intended for those who prefer to start with a blank slate and install the stuff they need themselves. For convenience however I've flashed the "iot" image which has no GUI but does include the webserver and cloud9 IDE. Changes I've made:
- rootfs partition starts at offset 4 MB instead of 1 MB to align it with eMMC allocation group boundary.
- debian stretch has been added as low-priority APT repository and systemd has been upgraded. jessie's systemd is too ancient to e.g. make systemd-networkd usable, but upgrading the whole system seemed too risky.
- switched from connman to systemd-networkd since I had some networking issues but know absolutely nothing about connman. I haven't reenabled USB networking since it seemed pointless, but it would be easy to do so if desired.
- set APT setting to disable automatically installing packages "recommended" by installed packages since this tends to pull in a lot of crap.
- removed a lot of crap that got automatically installed (including parts of X11).
I've made some attempts at getting the web interface functional. It assumed you use it via USB networking rather than Ethernet, and used its hardcoded IP (192.168.7.1) in many places. I've replaced those with the hostname, which at least made the link to the cloud9 IDE work. Bonescript briefly worked but then broke again, dunno why.
URL of web interface is just http://bbb/, or if the local DNS has stale records again use http://bbb.local/ (avahi to the rescue!). Cloud9 IDE is on port 9000. SSH login/password is debian/777.
I've also written a bunch of utility scripts:
gpio-parsecan convert between various ways of identifying GPIOssudo gpio-exportexports a GPIO via sysfs (accepts any format thatgpio-parse, prints the sysfs paths)sudo gpio-unexportremoves such exportssudo show-pinsdetailed overview of pin config and usage~/charger-info.plshows (some) status info of the battery charger state/etc/pmic-config.shconfigures the PMIC with more liberal charger settings. Invoked at startup by/etc/systemd/system/pmic-config.service.
Except for "show-pins", all of these were written from scratch on this BBB so you may want to make a backup if you intend to reflash the BBB.
Big buttons
The BBB has three pushbuttons:
- (S3) power button, next to the ethernet connector. Powers the system on when off. Shuts down the system when on (assuming proper OS config, since the PMIC obviously just sends an event). Hold for ~8 seconds to forcibly power cycle the system.
- (S1) reset button, next to the power button.
- (S2) boot button, somewhat nearby the μSD card slot. Pulls down pin 42 ("lcd_data2" / gpio 2.08) with 100Ω. If held during power-on this changes the boot device order from { eMMC, μSD, UART, USB } to { SPI, μSD, USB, UART }. This allows you to reflash the BBB via μSD or USB if the eMMC is hosed.
All three are annoying tiny buttons, but you can instead connect a more comfortable button between ground and the appropriate expansion header pin:
- (S3) power button: P9.09
- (S1) reset button: P9.10
- (S2) boot button: P8.43 (use 100Ω - 10KΩ series resistor for safety since pin may be configured as output)
Hardware capabilities
Note: this lists the functionality available on the BBB regardless of whether any software example exists. Not all peripherals have kernel drivers, and the drivers that do exist may support only a subset of the peripheral's functionality. In most cases however you can just mmap the peripheral registers (using /dev/mem or UIO) and use them directly like you would on a microcontroller. This is usually also a lot more efficient than having to go through the kernel. You can also receive IRQs in linux userspace using UIO, and if you're sufficiently nuts (like me) even set up DMA from userspace. For real-time needs you can run code on the two "PRU" cores, which can also access all peripherals and receive IRQs from many of them. Not all I/O listed can be used at the same time due to pinmux restrictions.
Peripheral names shown in italic.
Main CPU: 1 GHz Cortex-A8 with NEON, 32KB L1 icache, 32 KB L1 dcache, 256 KB L2 cache.
Memory: EMIF 512 MB DDR3L-800. 128 KB on-chip SRAM (64 KB private to cortex-A8; OCMC 64 KB shared).
3D GPU: PowerVR SGX-530. Requires non-mainlined open source kernel drivers and proprietary userspace libraries (no usage/redistribution restrictions). Supports OpenGL ES 1 and 2. Plenty of examples. Not supported by X11.
Storage: MMC0 μSD card slot. MMC1 4 GB on-board eMMC. MMC2 another MMC/SD/SDIO controller (max 8-bit 48 MHz) available via expansion headers. GPMC 8/16-bit bus controller (SRAM, NOR/NAND flash), pin-conflicts with eMMC, supports BCH-4/8/16 error correction codes for NAND flash including error location (ELM).
USB: USB subsystem with two Mentor "musbhdrc" USB 2.0 high-speed dual-role/OTG controller cores glued to TI custom PHYs and a complicated DMA controller. Known to be fickle at times. Officially used to provide one mini-B device port (USB0) and one host port (USB1), but this could be hacked into two host or two device ports with some creativity. A slightly odd feature is that UART2 and UART3 can also be routed to the data pins of USB0 and USB1 respectively, which then use standard 3.3V CMOS drivers instead of USB signalling.
Ethernet: The AM335x has an Ethernet switch subsystem with two gigabit ports, but only one port is usable on the BeagleBone and it connects to a 100Mbit PHY. Some guy managed to patch a gigabit phy onto it but I would not recommend attempting to recreate that epic hack. (Get a BBE for that)
Video out: LCDC display controller, max resolution 2048×2048 pixels, up to 24-bit color, max 126 MHz pixel clock. Connects to TDA19988 HDMI framer (max 16-bit color) and to expansion header P8. Can also directly drive passive-matrix screens, and various bus protocols typically used to interface with character displays (e.g. HD44780).
Audio: Two audio serial ports (ASP0, ASP1) supporting I²S or up to 16 channels/pin TDM in master or slave mode. Highly configurable formatting. Can also be configured in "burst mode" for non-audio data (SPI-ish). Can use the 24 MHz main oscillator as master clock or use one supplied externally. The BBB has a 24.576 MHz oscillator which drives it signal onto pin 107 (P9.25) for use by ASP0 on the BBB and/or external hardware as master clock for standard 48 kHz sample rate. Its output-enable is under software control and disabled by default to avoid conflicting with alternate uses of P9.25. ASP0 also connects to the HDMI framer to provide audio output over HDMI.
UART: 6 fancy UARTs which also support various IR protocols, and another simple but high-speed UART (max 12 Mbaud) located in the PRU subsystem. UART0 is used as console port, has a 6-pin header compatible with FTDI cables (only GND, RxD, TxD connected) and on-board 5V-tolerant isolation buffer to avoid damaging the cpu if a cable is connected while the BBB is powered off. The remaining ports are accessible via P9 and P8, including hw flow control. UART1 RxD is however lost due to damaged pin (but TxD can still be used).
SPI: Two SPI ports on P9: SPI0 with one hw chip select and SPI1 with two (although gpio chip selects are a fine alternative in master mode for most purposes). Supports 48 MHz clock or integer divisions thereof. SPI0 can be used as boot device if a compatible flash is connected.
I²C: Three standard (100 kHz) / fast (400 kHz) I²C ports: two (I2C1 and I2C2) accessible on P9, while I2C0 connects to local devices (PMIC, identification EEPROM, HDMI framer) and is not accessible via headers. I2C1 is enabled by default and used for automatic CAPE detection but it can also be used for other purposes or disabled entirely.
CAN: Two CAN controllers (Bosch DCAN) on P9, but CAN1 transmit lost due to damaged pin hence limited to passive bus sniffing. Max 1 Mbps. External transceiver required.
... work in progress ...