BeagleBone

BeagleBone Black
Participants	User:zmatt
Skills
Status	Seeking purpose
Niche
Purpose
Tool
Location	Space
Cost
Tool category

BeagleBone Black

Beaglebones.jpg {{#if:{{{Tool}}} | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:{{{Tool}}} | [[Tool Cost::{{{Cost}}} | }}

TL;DR

Donated BeagleBones seek projects that can give their life meaning. ARM Cortex-A8, lots of I/O, rich set of peripherals (CAN, ADC, high-res PWM, etc), hard real-time capability thanks to its pair of "PRU" cores (see these slides] for an example of what they can do).

Don't be afraid to play with them, or use one in a project! That's what they're for!

Do you want a 14-channel 100 Msps logic analyzer? Just run BeagleLogic on a BeagleBone!

Also, check out my py-uio project for directly working with the PRU subsystem (and various other peripherals) from python code. Poke me on IRC if you have questions, zmatt in #nurds (OFTC) and #beagle (Libera.chat).

Description

There are currently several donated BeagleBone Black (rev C) boards with minor defects, donated by my employer Dutch & Dutch:

• "boner". Has 3.3V regulator patch, battery header soldered on, and shown running on battery at the top of the page. 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.
• "ham-015". eMMC is dead.
• "bb-leds" (007357+1650). eMMC is dead. Has 3.3V regulator patch. USB mini-B and micro-HDMI ports have been desoldered.
• "8m-094". eMMC is dead. Has 3.3V regulator patch, battery header soldered on.
• "licht-gebakken". It's perfectly fine. No, really, I haven't noticed any problems with it.
• "not-a-phone". Idiot customer connected a phone line to the Ethernet port. PHY still works mostly, but link detection is wonky. Ethernet works if connected at power on, but hotplugging requires a tiny script (which has been installed) that periodically resets the PHY whenever network is down.
• "dead-pin-16". BeagleBone appears to have a production fault: cpu pin 16 (GPIO 1.16) appears to be internally shorted to 3.3V, and attempting to drive it low results in more than 100 mA of current. It has been disconnected from P9.15 by desoldering R160, and P9.15 remains usable thanks to its connection to cpu pin 34 (GPIO 2.00).
• "ham-059" (007270+1650). eMMC is dead. Has 3.3V regulator patch. USB mini-B and micro-HDMI ports have been desoldered.
• unlabeled (005857+1651). eMMC is dead. Has 3.3V regulator patch. USB mini-B and micro-HDMI ports have been desoldered.
• "julia" (XAN004945). eMMC is dead. Has 3.3V regulator patch.
• "8c-132" (005670+1634). eMMC is dead.
• unlabeled (000010+1720). eMMC is dead.
• unlabeled (002474+1823). unclear ethernet issues. worked fine on one switch, consistently didn't work on another switch.
• "8c-399" (003876+1823). expansion header pins P8.07-10 are solder blobbed together.
• unlabeled (004847+1850). sd card slot does not work.
• "8c-186" (004671+1729). No obvious problem, but has probably been exposed to ESD.
• "8c-421" (006510+1823). No obvious problem, but has probably been exposed to ESD.
• "8c-599" (000385+1838). No obvious problem, but has probably been exposed to ESD.

The BeagleBones with dead (worn out) eMMC need to boot from μSD card instead, or netboot if you're feeling adventurous.

When the USB mini-B port is missing, the beaglebone can be powered via 5V barrel jack or via expansion header P9 (connect P9.01 and/or P9.02 to ground, connect P9.05 and/or P9.06 to 5V)

The "3.3V regulator patch" means 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 top-left drawer, buried under some cruft maybe still somewhere in the space. If you intend to connect anything to the BBB keep these nearby for reference, and read the hardware safety notes below! For proper orientation, have the Ethernet connector facing up. P9 is then the connector on the left and P8 is on the right.

Playing with it

Overview

The bbb has been recently (4-12-2016) been reflashed with a basic firmware image (debian stretch with customizations). You can reach it with ssh dev@boner, password 777. There is a README file in the home directory, I might also put more details here if I get less lazy.

The OLED screen attached to it belongs to buZz, see ~dev/oled/README on the beaglebone for info on using 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 port inoperable due to invalid V_BUS 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).

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.

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 1kΩ - 10KΩ series resistor for safety since pin may be configured as output)

Hardware capabilities

BeagleBone Black components

• TI AM3358 ARM-based SoC
• 512 MB DDR3L-800 memory
• 4 GB eMMC flash (either Micron MTFC4GLDEA-0M WT or Kingston KE4CN2H5A-A58)
• SMSC/Microchip LAN8710A 100BASE-TX Ethernet PHY
• NXP TDA19988 HDMI framer
• TI TPS65217 power-management IC with Li-ion charger
• small I²C EEPROM for board identification

Unless mentioned otherwise, all the stuff below are features of the AM3358.

Processor subsystems

• Main CPU: 1 GHz Cortex-A8 with NEON, 32KB L1 icache, 32 KB L1 dcache, 256 KB L2 cache. Subsystem includes a small local interconnect, 64 KB of private SRAM, interrupt controller, and debug infrastructure. In its memory map, the private SRAM is directly adjacent to the shared 64 KB on-chip SRAM, allowing boot code to treat it as a single contiguous 128 KB SRAM for most purposes.
• 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. Supports Wayland but not X11.
  
• Wakeup controller: Cortex-M3 inside the always-on "wakeup domain". It has no ROM code hence needs to be initialized by the cortex-A8, after which it is available to assist in transitioning to/from suspend and other low power states, especially those where the cortex-A8 is powered off. It can also be programmed freely, but it has limited RAM and only has access to peripherals in the wakeup domain.
• Programmable Real-time Unit: Two 200 MHz PRU cores, ideal for code with strict timing or ultra low-latency requirements, contained in a subsystem together with local SRAM, an interrupt controller, and some peripherals.

Memory / storage

Peripheral names shown in italic.

• EMIF: 512 MB DDR3L-800.
• MMC0: μSD card slot (4-bit, max 48 MHz).
• MMC1: 4 GB on-board eMMC (8-bit, 48 MHz). Also connects to P8, see hardware safety notes.
• MMC2: unused MMC/SD/SDIO controller (max 8-bit, max 48 MHz) accessible 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 raw NAND flash including error location (ELM).

There are also SRAMs embedded in various subsystems and 64 KB of shared SRAM (OCMC) for general use.

A very flexible high-bandwidth DMA controller (EDMA) is available to transfer data between memories or to/from peripherals on software request or in response to hardware events. Some peripherals (e.g. Ethernet, LCDC) use integrated DMA instead.

Peripherals

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.

• 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. I2C2 is enabled by default and used for automatic CAPE detection but it can also be used for other purposes or disabled entirely. (It's currently not configured to support CAPE autodetection; it still enables I2C2 however to support the OLED display.)
• CAN: Two CAN controllers (Bosch DCAN) on P9, but CAN1 transmit is lost due to damaged pin hence it is limited to passive bus sniffing. Max 1 Mbps. External transceiver required.
• GPIO: Lots. Pretty much any pin can be used as GPIO, with support for debouncing and edge- or level-triggered interrupts. Any subset of the 32 pins of a GPIO bank can be set or cleared atomically with a single write. Inputs on GPIO0 can wake the system from suspend.
• ADC: 8-channel 12-bit ADC, 7 of which available on P9. Programmable sequencer, including differential measurements. Can inject a measurement sequence on various triggers. Some pins can be driven high or low during sequencer steps to allow direct connection of 4- or 5-wire resistive touchscreens (with support for waking system from suspend on pen touch). See hardware safety notes on this page.
• PWM: There are three dedicated PWM peripherals, each with two outputs, 16-bit counter with programmable limit running at max 100 MHz, two match registers with programmable actions, "dead time" generation for complementary outputs, and optional output chopper said to be "useful for pulse transformer gate drives". The modules can synchronize with each other with programmable phase difference. PWM0 also has external sync in and out. Output "A" of each PWM module also has a programmable delay line for ultrafine duty cycle or phase adjustment (fraction of a nanosecond). In addition, the four capture modules and timers 4-7 can be configured as PWM outputs, for a total of 14 hardware PWM outputs. One (CAP1) is not accessible on the expansion headers (though you can route it to the console tx pin or one of the JTAG pads), while the remaining 13 are (and usable simultaneously).

... work in progress ...