According to the datasheet of the TB6612FNG circuit have an output current: IOUT = 1.2 A(ave)/3.2 A (peak) but also a built-in thermal shutdown circuit. I first measured the running (0.2 A) and starting current (1.2 A) of my motors and then connected them to the board.

I tested the motors with "rc_test_motors" program from Robot Control Library and this worked fine. Meanwhile, I also added the "-s {duty}" argument which sweeps motors back and forward at duty cycle. I applied for test a very short duty cycle of level 1, which induced a very high current and the burned-out the driver IC.

In a pernicious way, after the incident, the drivers IC are sinking a very high current (dissipating a lot of heat) which caused a malfunction of the eMMC (read only file system). To continue to operate my BeagleBone, it was necessary to undersold the driver ICs with hot air. However, the conformal coating material was infiltrated between the circuit and the PCB making undersoldering impossible without raising the air hot temperature over 400 °C. This damaged the plastic connectors nearby, but my BeagleBone is still working.

• We recommend to use a fast current limiter because it seems that the built-in thermal shutdown circuit has in not fast enough for transient effects over-current protection.

The JST connectors are not compatible with the Grove cables. Seeed Studio has quoted some SMD versions of their connector.

Not required.

http://www.ti.com/tool/TIDA-00982#Technical Documents

Hello,

Working with a Beaglebone Blue rev A2, I have measured 5V on UART and EQEP encoder connectors, which is not consistent with the 3V3 defined in the schematic.

The connector that plugs inside is not retained. By vibrations, this connector comes out and this is particularly dangerous in the context of a flight controller (our project).

Please note I'm referring to the "Power out" and "4 ADC" connectors (see red arrow):

• We recommend to put also a white JST-SH connectors on the next version.

This would be to assist in new users locating specific connectors.

It is impossible to use the BBBlue, it always goes into read-only mode whenever there is a write attempt to eMMC or the SD card (32gb).
It also gives Input/Output error after it goes the read-only file system mode.

It's a very irritating bug, any fixes? or Is it a hardware issue?

Reduce number of characters

Commits 4e067f5 and f9327df corrupted the XML file. I plan to convert the XML file to CSV and request that @StrawsonDesign re-applies the changes and have @erikwelsh assist in confirming the document against the design.

Battery should not drain when device is powered down.

• Use a 4-pin JST like the other UART ports.
• No hardware handshaking.

2.5x5.5mm barrel jacks are far less common than the 2.1x5.5mm standard and are incompatible with the DC adapters found on Sparkfun.com, ebay, and amazon.

Hi,
This is my second broken BBBlue, breaking "the same way" I do have 5V line working, but not 3.3V anymore. I just understood the regulator is inside OSD3358 SIP A, and so part of the main chip, that I'm really unable to replace.
For once, I saw my BBB breaking (last time, it didn't boot after no use for a while): a bit intensive usage of two motors (on H1). ANyway, now, the ib led blink once a quater second, and disapear. I disconnected the 3.3V pin on h1, still not working. So now... Why the 3.3 power is going through the main processor, instead of going through a succincte regulator?( for the driver, and for output lines too.

At last, is it possible to get a new board Asap? my supplyer will think I'm just bad, and might be lazy to change my boards, as: I broke (but repaired) the usb connector, got this 3.3V problem twice, got the flash chip burnt one day after getting it (really heating a lot, still can boot a bit on SD), and at last got Q1 burnt (no reason, I changed it this morning)

• Add series resistor to I/Os
• Add (DNP) zener diods to I/Os

It would be helpful to be able to search for text in the pdf version of the schematic. You can fix this by going to Options > User Interface... in Eagle and unchecking Always vector font and Persistent in this drawing, then print to PDF.

• Move MDIR_1A from U18 to P9_12 (C12) to get MCASP0_ACLKR
• Move LED_2 from V12 to P8_32 (T5) to get MCASP0_FSR
• Move USB1_OCn from T16 to GPIO2_21 (M16) to get MCASP0_AXR0
• Remove HDMICLK_DISn from V17 to get MCASP0_AXR1
• Remove HDMI_INT from U16, just in case I need to get MCASP0_FSX

This is to try to match the UART5 mux. The TI Pin Mux Utility reports an error without this change.

Was the existing wiring verified?

I was checking out the LEDs and noticed that there is an LED named wl18xx_bt_en that is not actually an LED. It is defined in am335x-boneblue-wl1835.dtsi. Was this an LED in previous revisions of the board? I have rev A2.

It would be easier to identify the WiFi EN and BT EN LEDs if the BT LED was blue and the WiFi LED was green/yellow or some other color. Since we already have green LEDs on the board, perhaps that would be best.

Are these LEDs really all that useful if they are always on? They were helpful for initial debug, but it seems adding additional GPIO LEDs that could be bound to actual network state/activity would be more useful if other GPIOs can be found.

We had a bad signal intensity (as we where quite far from the router). Therefore, we tried to take out the WiFi antenna to obtain a better a signal intensity. Lot of pictures like https://github.com/beagleboard/beaglebone-blue/blob/master/docs/BeagleBone_Blue_balloons.png illustrate BBBL with the antenna out. Therefore, we don't saw any constraints to rotate the antenna.

To rotate the antenna there are two options:

1. Rotate the antenna without extracting it; the risk is to exert an asymmetrical tearing on the whole assembly when passing over the WiFi chip,
2. Extract the antenna from the receptacle, rotate the antenna 180° and push back the antenna on the receptacle.

Option 1 works quite well (tested by me, but not sure that it does not cause exfoliation of the printed circuit board). Option 2 causes the tearing of the receptacle (what happened to my father) because the anchoring of the receptacle on the printed circuit board is only superficial. Therefore, the required extraction force is bigger than the force that the attachment can support. Please note that we applied the instructions of the Hirose Electric connector manufacturer, consisting to to pull off vertically the U.FL Cable Assembly, in the direction of the connector mating axis (we don't used the extraction tool but but some plastic tweezers):

• We recommend that on the next version, the anchoring of the receptacle on the printed circuit board must be stronger (attached to a anchorage pin inserted in the PCB); some extraction test should be made on the first prototypes.
• For the meantime, a warning notice should be present with the product.

• Needs to comprehend fail-safe flashing/re-flashing at system level

Currently we have a large robot that is using the GPS UART-RX and UART-TX as PWM outputs for an H-Bridge that only allows a PWM logic level of 5.5v max (this is why we are not using the on board motor outputs). During boot our PWM pins get pulled high which is an issue because it causes the robot to start moving.

Is there a way to configure pins to stay low on boot to avoid this issue?

Had this board for a day. Powered it on and opened the getting started page. RNDIS tethering doesn't work on OS X Yosemite. Serial connection doesn't work unless you download full drivers from FTDI. I tried accessing beagle bone access point but don't know the password. Was able to login through the terminal with default password, but don't know how to update software without network connection. Now beagle bone doesn't seem to be working - not able to browse device files in Finder window; won't connect serially; can't see access point; and RNDIS won't work. Any other way to access beagle bone?

6V_REG works on cape but only starts when no load is present on Blue. Cause is likely the 1nF capacitor C21 on Blue. Should change to 0.1uF to match cape.

• Need to still be able to do boot-up debug by disabling Wilink8
• Means that only monitoring is possible when Wilink8 is active, not serial/debug console

• Use UART0_RTSN (E17) for SPI1_CS0, moving from pin C12.
• Use pin A15 for SPI1_CS1, moving from pin C18.

• Could we bundle pig-tails?
  • estimate about $0.10 cost each and likely to bundle about 6 of them
  • 6-wire: https://www.sparkfun.com/products/10361
  • 4-wire: https://www.sparkfun.com/products/9916
  • 2-wire: https://www.sparkfun.com/products/9914
• Where is the documentation for where to buy them?

Why we like them:

• small
• easy to plug and remove
• stay connected well
• readily available

Hi, is it an option to connect the MPU 9250 via SPI and not via I2C? With Ardupilot we can sample at 4 kHz / 8 kHz (acc gyro) in this case I2C is not fast enough for the data transfer. It is possible to sample slower too, than the transfer speed via I2C should be okay.