[Neeraj Dantu]

Lanwer,

The input voltage for the LDO TL5209 is provided by the PMIC SYS_VOUT voltage rail, which has its own drop out voltage from the power inputs to the PMIC. We can only guarantee the performance of the device within the specification of the device in the datasheet. There are a number of LDOs with better drop-out characteristics you could explore using external to the OSD335x-SM SiP.

Best regards,

Neeraj

[Neeraj Dantu]

Dusty,

Apart from isolation, you could try having a stronger pull up on SYSBOOT[14]. Looks like a 10K instead of the 100k pull up would push the pin over the digital threshold. However, you will need to make sure that the stronger pull up does not cause any timing issues on the communication signal on the pin and you would have to live with the additional power dissipation on the pin.

Neeraj

[Neeraj Dantu]

Dusty,

2 things here:

1. Please verify that the crystal clock input is 24MHz using an oscilloscope. You can probe OSC0_IN(P16) or OSC0_OUT(N16)

2. Please verify the SYSBOOT configuration on SYSBOOT[15:14]. These 2 most significant bits in the SYSBOOT pins set the clock speed configuration. So, a mismatch between the configuration here on the SYSBOOT pins and the clock input on OSC0_IN can cause a different clock to be set on the UART interface which by default is at 115200 setting. SYSBOOT[15] (MSB) should be pulled down and SYSBOOT[14] should be pulled high for the 24MHz setting. Please see ‘Table 26-7. SYSBOOT Configuration Pins’ in AM335x Technical Reference Manual (https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) for SYSBOOT configuration options.

Neeraj

[Neeraj Dantu]

VDDS_OSC is internally tied to 1.8V power rail. Please refer OSD3358-SM-RED schematics for an example oscillator circuit: https://octavosystems.com/docs/osd3358-sm-red-schematics-pdf/

[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.

[Author]

Posts