beagleboard / beaglebone-black Goto Github PK

On page 85 of file BBB_SRM.pdf, Rev C.1, we can read:

• “# Both of these signals connect to pin 41 of P11.”
• “@ Both of these signals connect to pin 42 of P11.”

But there is no P11 connector. In fact, this is the section talking about P9 so P11 should be replaced by P9.

There is an issue in the way the reset circuity on the BBB resets the 8710A ethernet PHY.

When coming out of reset, the 8710A can end up in an indefinite state as a result. This is problematic because you can loose the ability to communicate with the BBB occasionally and it requires a physical reset to clear the problem. For a remote system if a difficult to reach location this creates a major problem.

We have found that you can hack the current pcb (Rev B or Rev C) and disconnect the reset line from the 8710A. Then, hack a wire from the 8710A reset pin to a GPIO on the BBB. Now, when the ethernet PHY hangs it can be reset by asserting the GPIO pin.

I would like to recommend a revision to the PCB to address this issue. At the moment the reset trace near the 8710A is on an inner layer and not easily accessible. It would be a big help if the trace was more easily accessible. It would be an even bigger help if there was a jumper and a couple pads.

We would be happy to contribute the firmware driver we developed for this.

I have an analog signal of (0-5V). I want to use the ADC of BeagleBone Black to process it, but the ADC inputs can take a maximum of 1.8V. If I down-scale the signal to (0-1.8V), then -

How should I do this ensuring no loss/minimum loss of information or resolution? If there is some loss, then is there any way to retrieve the original signal after processing it with the ADC of BeagleBone Black?

Hi,

The TPS65217 is not available anymore, how can we replace it ?

The industrial version of BeagleBone Black can't be logged in as the debian or root account. The password can't be typed in.

I am confused about one thing. If I design a BeagleBone Cape Board without EEPROM and use it with BeagleBone Black, then will that Cape Board work just like a PCB board? @RobertCNelson @jadonk @pdp7 @MarkAYoder

TL;DR: How to access a mikroE click module via SPI using a BeagleBone Black and a mikroBus Cape?

Hello,
I'm currently trying to connect my BeagleBone Black Rev C with the mikroBus Cape (PID: MIKROE-1857).
Furthermore, I want to get access to a MRAM click module (https://www.mikroe.com/mram-click) by connecting it with the mikroBus Cape. My BBB is running the latest Debian image (AM3358 Debian 10.3 2020-04-06 4GB SD IoT) and with uname_r=4.14.108-ti-r141.

Firstly, I tried to work with U-Boot overlays:

I followed the instructions on https://elinux.org/Tigal:BeagleBone_mikrobuscape but used the updated url "https://github.com/mikroe/BBB-mikroBUS-Cape". But, after setting the "uboot_overlay_addr0=/lib/firmware/BB-MIKROBUS-01-00A1.dtbo" in the uEnv.txt the board would not boot.

I followed the instructions on "https://github.com/beagleboard/bb.org-overlays/" and I also upgraded my bootloader (https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays). After setting all four BB-MIKROBUS-CAPE-X.dtbo files in "uboot_overlay_addrY=..." the board booted. (It also boots when only one is enabled)

Next I wanted to get access to the click module on the mikroBus Cape.

A.
I downloaded the mikroSDK 2.0 (https://www.mikroe.com/mikrosdk) on the BBB, but I couldn't find nor create the correct board.h file to get it running. After stumbling upon "NectoStudio" I could only find support for generic ARM boards which are from the STM32 family, which the BBB Rev C is not. (Getting access to the mikroSDK 2.0 would allow the usage of scripts via https://libstock.mikroe.com/ which would open up many other possibilities)

As I couldn't get the mikroSDK 2.0 working, I tried to get direct access via SPI to the click module. For that I put the click module on the mikroBus Cape slot 3 (CS - Pin 17, D1/MISO - Pin 21, D0/MOSI - Pin 18 and CLK - Pin 22).

B.
After some research I found the iobb library and followed its instructions
(https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/15/beaglebone-black-bbb-io-gpio-spi-and-i2c-library-for-c-2019-edition).
After installation, I tried to run the example SPI code without any changes (so not using option 2.) and it runs error-free. But when I enable the BB-MIKROBUS-CAPE-3.dtbo I always get "ERROR: open() for /sys/devices/platform/ocp/ocp:P9_17_pinmux/state failed, No such file or directory" So, after some investigation I realised that BB-MIKROBUS-CAPE-3.dtbo sets "P9_X_pinmux { status = "disabled"; };" for X = {18,19,21,22} and doesn't enable spi in its pinctrl-section, which could be the cause for the problem.

So I tried two things:

• I just used BB-MIKROBUS-CAPE-2.dtbo which doesn't set "P9_X_pinmux { status = "disabled"; };" for any X = {18,19,21,22} and the example code ran error-free.
• I changed BB-MIKROBUS-CAPE-3.dtbo so that spi gets enabled in the pinctrl-section and the example code ran error-free.

To my understanding both of this ways should enable SPI, but when I try to read previously written data from the click module, I can't receive any data at all or select a cell to write to.

So, is there a way to get any of my attempts working so that I can get access to the click module via SPI? Or have I overlooked an other solution?

Btw:

• I tried all solutions on the board itself and on a microSD card which I set up using https://beagleboard.org/getting-started
• I also tried it with and without setting "disable_uboot_overlay_video=1" in the uEnv.txt

BBB design uses the PMIC which is extremely suitable for a battery powered applications. In such applications, it's essential for the SW to be aware of the battery voltage. The PMIC integrates analog multiplexer, that can provide this information. In the BeagleBone design, the multiplexer's output (MUX_OUT pin) is routed to AN7 input of the processor and this is fine.
For some reason, in the BBB design that feature is broken and the MUX_OUT pin is left not connected. So the customers wishing to get it back having to exercise their soldering skills. Because of the PMIC part dimensions, it's a bit difficult to solder a wire to the MUX_OUT pin manually.
If it's a problem to completely fix the PCB routing in the future revision, I'd like to propose to implement a workaround in the form of test point via on the PCB somewhere near the MUX_OUT pin of the PMIC. That will simplify the soldering work.

The BBB has three 3.3V supply rails:

• VDD_3V3AUX from PMIC LDO3 (100 mA) is only used for the power led
• VDD_3V3A from PMIC LDO4 (400 mA) is used for the AM335x 3.3V I/O supplies and a few miscellaneous on-board uses
• VDD_3V3B from discrete LDO U4 (500 mA) is available on P9 for external hardware and also used for various on-board uses such as eMMC, μSD card, ethernet phy, and the console uart buffer.

Since 3V3B is used to drive signals into the AM335x, it is critical this supply comes up after (or simultaneous with) 3V3A. The BBB attempts to ensure this by simply using 3V3A as enable-signal for 3V3B, which has the desired result during power-up. During power-down however a problem arises: current injected from 3V3B into AM335x I/Os flows leaks back onto 3V3A (via protection diodes inside the AM335x) which causes 3V3A to remain high enough to keep 3V3B permanently enabled as long as SYS_5V continues to supply LDO U4.

The impact is easily visible in a scope capture of the power-off sequence:

• t = 0 ms: PMIC starts power-off sequence by deasserting PGOOD and (bizarrely) cutting power to SYS_5V, which means the system is now running on capacitors only
• t = 2 ms: DCDC2 and DCDC3 supplying VDD_MPU and VDD_CORE respectively (not depicted) are shut off
• t = 3 ms: LDO4 supplying VDD_3V3A is shut off, but VDD_3V3B remains on
• t = 4 ms: LDO2 supplying VDD_3V3AUX (not depicted) is shut off, SYS_5V has fallen to 3.5V and VDD_3V3B is starting to track SYS_5V - 0.1V
• t = 9 ms: LDO3 supplying VDD_1V8 is shut off
• t = 10 ms: DCDC1 supplying VDDS_DDR (not depicted) is shut off
• t = 11 ms: LDO1 supplying VRTC (not depicted) is shut off and LDO_PGOOD is deasserted, finishing the PMIC's power-off sequence
• t = 20 ms (approx): LDO U4 supplying VDD_3V3B finally shuts off

As a result, the absolute maximum ratings of the AM335x (max I/O voltage = supply voltage + 0.3v) are violated for about 15 ms on each power-off. Whether this has any long-term reliability impact in practice is unclear.

A far more serious situation occurs when the PMIC battery terminals are used to power the system, in which case SYS_5V is always-on and as a result LDO U4 never shuts off at all:

In this state there's about 35 mA continuously flowing from 3V3B into the AM335x (and back out to 3V3A) via pull-ups on about two dozen pins. However if one makes the mistake of having a serial console cable connected during this, the console uart buffer (powered from 3V3B) drives 45 mA of current into UART0_RXD, causing 3V3A to be raised more than 2V above the 1.8V supplies, a situation the am335x datasheet repeatedly and emphatically warns must be avoided under all circumstances. Yikes.

Note that this is actually an ancient issue dating all the way back to the BeagleBone White (discussion thread), whose LDO U8 supplying VDD_3V3EXP suffered from the same problem, except it had no on-board leakage paths into AM335x I/O like the BBB does (but external hardware powered from VDD_3V3EXP easily creates such paths obviously). It also affects the OSD335x whose power scheme was copy-pasted from the BBB.

In Figure 39 of the user manual, first in the boot sequence when the boot switch is pressed, is "SPI0".
The text states: "On boot, the processor will look for the SPIO0 port first". So the label between these is not consistent.

Comment on the text:
Section 5.3.5 discusses 4 different boot modes, eMMC Boot, SD Boot, Serial Boot and USB boot. It could be helpful (especially for beginners) to relate back to these boot modes in section 6.8 (possibly in relation to figure 39). The text about the serial boot especially feels unconnected to section 6.8: "Serial Boot…This mode will use the serial port to allow downloading of the software direct. A separate USB to serial cable is required to use this port."

I'm assuming that booting from SPI0 or UART is booting in the serial mode, but I cannot confirm this anywhere just by reading the text.

What license are the design files under?

I'm looking into if this qualifies as free hardware as defined by the Free Computing Movement (which is basically me for now...).

If you guys are thinking, maybe GPL v3 or CERN 2.0 (strong copyleft)?

Hello,

I found that the hardware is in fact a Teensy but I am not aware of what type/version. Is the Teensy type a Teensy++ 2.0?

Seth

P.S. Sorry, the USB device is what I am discussing.

Hello Friends,

I would like to create a KiCad version of the REVC board, and I think we could do so by converting the allegro file to a .alg file, then, saving the files as altium files, and then using scripts to convert these files to KiCad.

I don't have allegro installed though, and don't have the "ascii" files altium would need to import, as seen here.

https://www.altium.com/documentation/altium-designer/allegro-import?version=19.1

Could you share with us these files?

ALPS has discontinued SCHA5B0200 without an alternative or replacement. If there is a suitable replacement from a different manufacturer the BOM should be updated.

P10 Connector SD/MMC ALPS SCHA5B0200

Dear Alex Ferm,

Thank you for your interest in Alps Electric.

With regard to your inquiry, we apologize but Alps discontinued all card connectors with no replacements or alternatives.

Best regards,

Lourdes Olanio

Sales Representative

Alps Electric (North America), Inc.

Hi, i have a problem with BBB.

I have two sd images and both worked fine.
Then during work it disconnected from PC, i tried to reboot it, but reboot fails with this log with both sd cards:

U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.img

U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: not set. Validating first E-fuse MAC
Phy not found
PHY reset timed out
cpsw, usb_ether
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
33 bytes read in 4 ms (7.8 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
gpio: pin 55 (gpio 55) value is 1
4381184 bytes read in 816 ms (5.1 MiB/s)
gpio: pin 56 (gpio 56) value is 1
24238 bytes read in 55 ms (429.7 KiB/s)
Booting from mmc ...

Booting kernel from Legacy Image at 80007fc0 ...

Image Name: Linux-3.8.13
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4381120 Bytes = 4.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK

Flattened Device Tree blob at 80f80000

Booting using the fdt blob at 0x80f80000
XIP Kernel Image ... OK
OK
Using Device Tree in place at 80f80000, end 80f88ead

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[ 0.190418] omap2_mbox_probe: platform not supported
[ 0.200964] tps65217-bl tps65217-bl: no platform data provided
[ 0.276307] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed
[ 0.340932] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[ 0.352646] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[ 0.359960] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[ 0.464476] Unhandled fault: external abort on non-linefetch (0x1008) at 0xe09e2000
[ 0.472492] Internal error: : 1008 [#1] SMP THUMB2
[ 0.477498] Modules linked in:
[ 0.480701] CPU: 0 Not tainted (3.8.13 #12)
[ 0.485448] PC is at cpsw_probe+0x3ee/0x88c
[ 0.489840] LR is at ioremap_page_range+0xad/0xe8
[ 0.494761] pc : [] lr : [] psr: 80000133
[ 0.494761] sp : df051e20 ip : e09e4000 fp : df3c6590
[ 0.506753] r10: df3784a0 r9 : 00000000 r8 : df10d800
[ 0.512214] r7 : df10d810 r6 : e09e2000 r5 : df3c6540 r4 : df3c6000
[ 0.519033] r3 : 00000000 r2 : 00000800 r1 : c0250e03 r0 : e09e2000
[ 0.525855] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel
[ 0.533674] Control: 50c5387d Table: 80004019 DAC: 00000015
[ 0.539678] Process swapper/0 (pid: 1, stack limit = 0xdf050240)
[ 0.545954] Stack: (0xdf051e20 to 0xdf052000)
[ 0.550517] 1e20: 00000000 c06a7440 00000001 df3c6298 df04cac0 df3c9548 00000000 df051e88
[ 0.559069] 1e40: df10c408 c00d0f2f 22222222 df3c9548 df3cae40 df3c9548 df051e88 c00d0e77
[ 0.567620] 1e60: df04cac0 df3c9548 df3c9548 00000000 df3c95c8 c00d1557 df0474b8 c004184d
[ 0.576171] 1e80: 00000000 00000003 00000008 00000020 df10d844 df10d810 df10d844 c072b1fc
[ 0.584722] 1ea0: c072b204 c06beb18 00000000 00000000 00000000 c0201597 c020158b c0200b37
[ 0.593272] 1ec0: 00000000 df10d810 df10d844 c06beb18 00000000 c06d9d80 00000000 c0200c45
[ 0.601823] 1ee0: c06beb18 c0200c15 00000000 c01ffd5f df047478 df104580 c06beb18 df3cae40
[ 0.610375] 1f00: c06b5380 c02005d1 c054e5f7 c054e5f8 c06beb18 c064e048 c064e028 c0644ffd
[ 0.618926] 1f20: c06d9d80 c0201025 00000007 c064e048 c064e028 c0644ffd c06d9d80 00000000
[ 0.627477] 1f40: 00000000 c0008661 00000007 00000007 c06a27e0 00000007 c064e044 00000007
[ 0.636028] 1f60: c064e048 c064e028 c06d9d80 000000f6 c0660134 c062d65d 00000007 00000007
[ 0.644578] 1f80: c062d15d c0399955 00000000 00000000 c0399955 00000000 00000000 00000000
[ 0.653128] 1fa0: 00000000 c039995b 00000000 c000c5f9 00000000 00000000 00000000 00000000
[ 0.661677] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.670227] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 fe75e5cd a7652d8e
[ 0.678808] [] (cpsw_probe+0x3ee/0x88c) from [] (platform_drv_probe+0xd/0xe)
[ 0.688005] [] (platform_drv_probe+0xd/0xe) from [] (driver_probe_device+0x77/0x154)
[ 0.697923] [] (driver_probe_device+0x77/0x154) from [] (__driver_attach+0x31/0x44)
[ 0.707750] [] (__driver_attach+0x31/0x44) from [] (bus_for_each_dev+0x27/0x44)
[ 0.717215] [] (bus_for_each_dev+0x27/0x44) from [] (bus_add_driver+0x65/0x158)
[ 0.726678] [] (bus_add_driver+0x65/0x158) from [] (driver_register+0x4d/0xac)
[ 0.736052] [] (driver_register+0x4d/0xac) from [] (do_one_initcall+0x65/0xf0)
[ 0.745429] [] (do_one_initcall+0x65/0xf0) from [] (kernel_init_freeable+0xb9/0x14c)
[ 0.755352] [] (kernel_init_freeable+0xb9/0x14c) from [] (kernel_init+0x7/0x90)
[ 0.764821] [] (kernel_init+0x7/0x90) from [] (ret_from_fork+0x11/0x38)
[ 0.773554] Code: fe26 e208 f8c4 05c0 (6803) f44f
[ 0.778565] ---[ end trace 3b1325c5f0465841 ]---
[ 0.783690] mmc1: BKOPS_EN bit is not set
[ 0.787989] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.787989]
[ 0.797540] drm_kms_helper: panic occurred, switching back to text console

At first we got all four LEDs on, then only LED 2 stays on, and kernel doesn't boot.
Could you help to determine where the problem is and whether it can be fixed?