[Neeraj Dantu]

Dion,

1. OSCx_GND pins are connected to ground inside the SiP. So, there is no need to have an external ground connection for the OSCx_GND

2. You can connect the ground pin of the oscillator to DGND or to OSCx_GND as the pin is connected to ground internally

Neeraj

[Neeraj Dantu]

Mahmoud,

It is not necessary to connect the PMIC_MUX_OUT to AIN7. The reason that was done in the reference design was to have an option for an application level check on the power rails(mainly VSYS) that PMIC_MUX_OUT exposes(See section 8.3.8 Analog Multiplexer in TPS65217C datasheet: http://www.ti.com/lit/ds/symlink/tps65217.pdf).

The question of if you should monitor the power rails(please refer to the Analog Multiplexer section of the PMIC datasheet to see what power rials, the PMIC_MUX_OUT gives access to) depends on your system requirements. Is it a system, in which you would have to detect when there is a power rail failure on for example SYS_VOUT, and perform additional tasks to address it? If so, it is a good idea to have an application software check on power rail health.

Also, you do not need to use the ADC subsystem to monitor the health of the power rials. You can have external circuitry on the power rails you want to monitor, detect failure and trigger actions.

Neeraj

[Neeraj Dantu]

G,

There are more than one ways to prototype with CAN bus.

1. BeagleboneBlue comes with a CAN PHY on board(https://beagleboard.org/blue)

2. You can use a CAN evaluation module(ex: http://www.ti.com/tool/tcan1042devm) and wire it up to RED board

3. There are several DIY solutions. A couple are linked below, but not tested by Octavo:

– http://www.thomas-wedemeyer.de/beaglebone-canbus-python.html

– http://www.instructables.com/id/DIY-Beaglebone-CAN-Bus-Cape/

Hope that helps

[Neeraj Dantu]

Wilt,

Yes, OSD335x and oSD335x-SM suffer from the same 3V3B regulator bug when using battery. We have no plans to remedy this in the current devices, but have more devices in development that do. Please contact Octavo Sales for more information.

Unfortunately the power switching functionality is internal to the PMIC. But, you can use an external power controller like an MSP430FR2000(http://www.ti.com/product/MSP430FR2000) to achieve the functionality you mentioned.

[Neeraj Dantu]

Dave,

The reset supervisor APX811 is a clone of MAX811 which has an internal pull-up resistance of 10K. We have measured the presence of this internal pull up on APX811. The datasheet of APX811 just doesn’t specify the pull-up but it is present.

Hope that helps,

Neeraj

[Neeraj Dantu]

Mike,

The kernel has been patched: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/6643bcf15b1379c5bbcde801106b5b65f04df058#diff-ba79210cd3316674807a5388d265a3f2 

Note that the patch is for 4.14.36-ti-r45 kernel

• This reply was modified 6 years, 11 months ago by Neeraj Dantu.

[Neeraj Dantu]

Mike,

That was good info. We went and looked at the kconfig files of Debian and Ubuntu images and it looks like the kernel in the Debian image was setup to load the 8035 driver as a kernel module vs the kernel in the Ubuntu image was not (These files can be found in /boot folder):

Ubuntu (config-4.14.34-ti-r43)
#
# MII PHY device drivers
#
# CONFIG_AMD_PHY is not set
# CONFIG_AQUANTIA_PHY is not set
# CONFIG_AT803X_PHY is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_CORTINA_PHY is not set
# CONFIG_DAVICOM_PHY is not set
CONFIG_DP83848_PHY=y
CONFIG_DP83867_PHY=m
CONFIG_FIXED_PHY=y
# CONFIG_ICPLUS_PHY is not set
# CONFIG_INTEL_XWAY_PHY is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_MARVELL_10G_PHY is not set

Debian (config-4.9.82-ti-r102)
#
# MII PHY device drivers
#
CONFIG_AMD_PHY=m
CONFIG_AQUANTIA_PHY=m
CONFIG_AT803X_PHY=m
CONFIG_BCM7XXX_PHY=m
CONFIG_BCM87XX_PHY=m
CONFIG_BCM_NET_PHYLIB=m
CONFIG_BROADCOM_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_DP83848_PHY=y
CONFIG_DP83867_PHY=m
CONFIG_FIXED_PHY=y
CONFIG_ICPLUS_PHY=m
# CONFIG_INTEL_XWAY_PHY is not set
CONFIG_LSI_ET1011C_PHY=m
CONFIG_LXT_PHY=m
CONFIG_MARVELL_PHY=m
CONFIG_MICREL_PHY=y
CONFIG_MICROCHIP_PHY=m
CONFIG_MICROSEMI_PHY=y
CONFIG_NATIONAL_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_SMSC_PHY=y
CONFIG_STE10XP=m
CONFIG_TERANETICS_PHY=m
CONFIG_VITESSE_PHY=y

This is pretty conclusive evidence. We have not tried it, but once you modify your kconfig file to load the driver for Atheros 8035 PHY during the building process, the image should function normally. This has also been notified to Beagleboard Ubuntu maintainers.

Thanks,

Neeraj

[Neeraj Dantu]

Mike,

Here is an update for this issue:

The board boots and loads the PHY driver. As indicated by the LED activity on the connector and ifconfig, it looks like there is data transfer on Tx and Rx interfaces. However, there is no DHCP/ARP request going out on the network connected to the board. I don’t think there is an issue with the protocol stack as I am able to use a USB WiFi dongle to connect to the internet and install packages.

When it is connected to an ethernet switch on the network, the board is able to capture packets on the network using tcpdump, so, the rx interface seems to be working fine.

We are currently trying to see if there a configuration issue with the PHY.

[Neeraj Dantu]

Mike,

From the updated bootlog minicom-2.txt, it looks like the ethernet PHY is being probed successfully (lines 226-233). Ubuntu is also trying to bring the ethernet interface (eth0) up at line 461. I am not sure whether it is succeeding.

Can you run ‘systemctl status networking.service’ to see if the networking daemon is running?

I will go through the build process for Ubuntu and try to debug on this side, meanwhile, please let me know if you make progress.

[Neeraj Dantu]

Can you please post the complete boot logs? The Ethernet PHY on OSD3358-SM-RED is different from the Beaglebone black. So, the default device tree am335x-boneblack.dtb will not bring up the Ethernet interface. The first step is to make sure the device tree file osd3358-bsm-refdesign.dtb is installed correctly. Here is a procedure to install the device tree just in case:

1. Download the OSD3358-SM-RED device tree from https://github.com/octavosystems/OSD335x-Device-Tree It is in OSD3358-SM-RED folder.

2. Copy the device tree file osd3358-bsm-refdesign.dtb into /boot/dtbs/[kernel version]/ folder

3. Edit the variable ‘dtb’ in /boot/uEnv.txt to say ‘dtb=osd3358-bsm-refdesign.dtb’

 

[Neeraj Dantu]

Beagle images do not require the connection between PMIC_MUX_OUT and AIN7. This was done just in case we would want to have some software checks in place to determine the health of PMIC power rails that PMIC_MUX_OUT provides access to. You can go ahead and disable the ADC subsystem in hardware.

[Neeraj Dantu]

Joe,

Here is what I would go through to bring your board up and running:

1. Bypass the EEPROM check in Beagleboard image(https://beagleboard.org/latest-images) by following the instructions here and boot the board:

https://octavosystems.com/forums/topic/osd3358-boot/#post-4733

2. Program the EEPROM by grounding the EEPROM_WP of the OSD335x-SM to boot standard beagle images. There are a couple of ways of doing this. You can boot patched Linux image from sdtep 1 and use the SYSFS interface to write the ID to EEPROM directly. You can also use the I2C commands in u-boot to program the EEPROM: http://beagleboneblack.blogspot.com/2016/01/bbb-magic-number-programming.html.

3. Use the device tree rebuilder(https://github.com/RobertCNelson/dtb-rebuilder) to modify the RED board device tree source files(https://github.com/octavosystems/OSD335x-Device-Tree) to reflect the hardware on your board and compile it to .dtb. This is the kernel device tree. You should more than likely not have to modify the u-boot device tree.

4. Place the custom .dtb file in /boot/dtbs/[Kernel Version]/ and modify dtb variable in /boot/uEnv.txt to your custom device tree file

Your board should boot up with the custom device tree at this point and you should be able to start integrating your software. Make sure you can access your SD card offline through a host computer so you can iterate the device tree modifications easily.

You should not have to modify u-boot in order to boot the board. If you want to, you can use a u-boot overlay to customize the boot(https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays). Here is a repository of overlays: https://github.com/beagleboard/bb.org-overlays .If you see strange behavior in u-boot, it may be  because u-boot prefers to boot Linux from the MMC0 interface and this may result in some things not working as they do in the standard beagle image configuration. In this case you have to modify some u-boot config files to work around this.

 

[Neeraj Dantu]

Hi Gary,

From the schematics you provided us, the Atmega2560 looks like it is connected to pins (A13, B13) which are pins for UART2 and not UART3.

The interface does need to be enabled in device tree. You can also specify a device tree overlay to instantiate the UART interface. For this, you will need to modify uEnv.txt located on /boot folder. You will need root privileges to modify this file. So, make sure you are root.

I made 2 modifications to this file:

1. uncommented uboot_overlay_addr0 and specified BB-UART2-00A0.dtbo as the device tree overlay(changes shown below)

###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###

2. Commented the line to enable universal cape(shown below).

###Cape Universal Enable
#enable_uboot_cape_universal=1

Then I rebooted the board. I was able to see that UART2 was available as ttyO2:

root@beaglebone:/var/lib/cloud9# ls -l /dev/ttyO*
lrwxrwxrwx 1 root root 5 Mar 20 16:16 /dev/ttyO0 -> ttyS0
lrwxrwxrwx 1 root root 5 Mar 20 16:16 /dev/ttyO2 -> ttyS2

In order to test the interface, I used a UART to USB FTDI cable and connected it to my computer. I monitored the connection using Putty with baud rate 9600.

On the board, I installed minicom which is a serial console program.

sudo apt-get install minicom

I ran the following command to start a communication terminal on the board.

root@beaglebone:~# minicom -D /dev/ttyO2 -b 9600

I then input some characters and verified that they were showing up on my computer’s Putty terminal.

Hope this helps,

Please let us know if you have any more questions.

 

 

[Neeraj Dantu]

Gary,

I fixed the post I linked to to display the correct special character. We are currently working on an Application note that goes through working with EEPROM IDs. Please let us know if you have any more issues and look out for the application note.

Neeraj

[Neeraj Dantu]

Gary,

I just reviewed the post and found the editor on the forum does not handle the special character “`” well. In step 1, code line 3, please add the special character on both sides of the word pwd and let us know if that fixes the error.

Neeraj

[Author]

Posts