[Neeraj Dantu]

Great! Thanks for the update. Very cool looking board.

Neeraj

[Neeraj Dantu]

If the board shows shorts on the rails you have listed even before it is powered up, it would point to a manufacturing issue. Solder bridging could be the cause.

Also, from a design point of view, make sure none of the devices that connect to the OSD335x drive the IO pins for the OSD335x-SM before the device completely powers up as that can cause faulty behavior.

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

[Neeraj Dantu]

Glad you are able to resolve the issue. Thanks for letting us know. We plan to create more collateral around CAN bus and Buildroot in the future.

Neeraj

[Neeraj Dantu]

Samy,

From the boot logs, it looks like the processor is unable to detect the ethernet PHY by probing the MDIO interface. We will be reaching out to you shortly for a closer look at your PHY hardware configuration.

Neeraj

[Neeraj Dantu]

Samy,

If you are using the same hardware configuration as Beaglebone Black (same circuit with PHY connected to AM335x on MII1 and MDIO interfaces), you should be able to bring up the network without modification to the Beagle image, since you already have the magic number in your EEPROM. Coming to your question, the line is setting the PHY address ‘0’, i.e., the kernel is going to look for an ethernet PHY at address ‘0’ on the MDIO interface for identification and driver load. Note that the address of the ethernet PHY can be set in hardware (See section 3.7 in LAN8710 datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/00002164B.pdf).

Can you attach your boot logs for a closer look at the error?

Neeraj

[Neeraj Dantu]

Samy,

You can ignore the uboot error if you are not using ethernet at uboot. If you are unable to bring up the network after Linux boot, make sure you have the correct PHY address in the device tree. You can find the PHY address settings in the PHY datasheet. Here is an example of the PHY address setting on the Beaglebone Black device tree: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-bone-common.dtsi#L421

Best,

Neeraj

[Neeraj Dantu]

Samy,

Can you post the complete boot logs so we can determine where in the boot process is it entering this fault condition?

If this is from uboot, you could try halting the autoboot process when the board gets to uboot by hitting the space bar(You will have 2 seconds to do this). You will have a uboot command line from which you should be able to use uboot commands to stop the USB module and USB PHY.

Also, see http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot

Best,

Neeraj

[Neeraj Dantu]

Samy,

If you left the USB interface pins unconnected in your design, you should be able to just boot up Linux without issue. If you need to explicitly disable the USB ports, you will have to make a custom device tree that does not enable the USB subsystem. Please see https://github.com/RobertCNelson/dtb-rebuilder for examples of device trees you can modify.

More info on device tree: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/

Another way to achieve this is by changing kernel configuration options when you build the kernel. See http://e2e.ti.com/support/arm/sitara_arm/f/791/p/413913/1470309 for additional info.

Neeraj

[Neeraj 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 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, 7 months ago by Neeraj Dantu.

[Neeraj 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 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/

[Author]

Posts