[Neeraj Kumar Reddy Dantu]

Sid,

Regardless of what yo have already read through, here are some of the things we recommend:

1. Table 4.2 (Pin Attributes) from AM335x Datasheet (http://www.ti.com/lit/ds/symlink/am3358.pdf): This table gives you all the modes of each pin along with IO, reset state, power domain and pull-up/pull-down information you need. Make sure to refer to the ZCZ package ball numbers for OSD335x devices.

2. Table 9.3.1(CONTROL_MODULE Registers) from AM335x Technical Reference Manual (https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf): This table provides information of the registers that can be used to set the pinmuxing.

3. OSD335x design tutorial: Device Tree (https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/): Section 1.4 Pin Multiplexing provides an example of multiplexing by setting the pin control registers described above.

4. TI pinmux tool (https://dev.ti.com/pinmux/): This tool will help you organize your pinmuxing based on your system needs. It allows you to look at all the peripherals on the AM335x device. The IO sets for each of the peripherals will provide all the valid combination of pins that can be used for the peripheral. Since the pin numbers of the AM335x device and OSD335x are different, take a look at this pin mapping table: https://octavosystems.com/app_notes/osd335x-family-pin-assignments/ for your hardware design.

5.  Other useful links:

– http://www.righto.com/2017/12/hands-on-with-pocketbeagle-tiny-25.html

– https://cm.e-ale.org/2018/pocketbeagle/pocketbeagle.pdf  Video tutorial: https://www.youtube.com/watch?v=jvgDwkkKtBA

Hope that helps,

Please let us know if you have any questions in particular.

Neeraj

[Neeraj Kumar Reddy Dantu]

Due to the use of the TPS65217C PMIC within the OSD335x-SM, the RTC-only power mode is not available. There is an RTC within the OSD335x, however, the lowest power mode available is Deepsleep0. Please refer to our power application notes:

https://octavosystems.com/app_notes/osd335x-software-control-power-management/

https://octavosystems.com/app_notes/osd335x-sm-power-application-note/

for more information about low power modes and power budgeting.
The internal RTC module can still be used for timing functions, but not a low power mode.

• This reply was modified 6 years, 10 months ago by Neeraj Kumar Reddy Dantu.

[Neeraj Kumar Reddy Dantu]

Hey Lan,

Sorry for the delayed response. The specifications on our datasheet are based on our testing of the device. We do not guarantee performance outside these specifications, but you can try and see if it works for your case.

Our recommendation would be to use an external battery charger as in the Beaglebone Blue(https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf).

If the battery voltage falls below 3.6V(Look at battery curve here: https://learn.sparkfun.com/tutorials/battery-technologies/lithium-polymer), LDO4 for example will lose regulation because of the drop out voltage. This does not generate an action form the PMIC either. So, 2S LiPo with external charger as shown in Beaglebone Blue would be the best bet.

We do not plan to replace the LDO on OSD335x-SM.

Best regards,

Neeraj

[Neeraj Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 7 years, 1 month ago by Neeraj Kumar Reddy Dantu.

[Neeraj Kumar Reddy 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 Kumar Reddy 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.

[Author]

Posts