[Neeraj Dantu]

Hi boscoe,

Please check for shorts on IO signals of the board. Also measure the total current consumption and compare it to the expected current consumption of an equivalent design such as a Beaglebone. Monitor the thermal behavior of the board as well as that would indicate an abnormal power draw as well. A high power draw on one of the power rails could be causing the board to reset periodically. Also make sure that PMIC_PB_IN pin of OSD335x is not grounded as that causes the PMIC to power cycle(every 8 sec).

Apart from shorting/current draw there might be a specific component at fault. The processor has already booted at ~15 seconds, are there other components that are being powered up/initialized at ~15 seconds?

Plotting the main power rails including the power input, the PMIC/processor interface and power rails of various subsystems of the processor with an oscilloscope might be useful to pin point which power rail is at fault if that is the case.

Hope that helps. Please let us know how it goes.

Neeraj

[Neeraj Dantu]

Hi Calvin,

OSD335x C-SIP integrates the 24MHz main oscillator clock on OSC0. An external oscillator is required to generate the 32KHz real time clock for the RTC subsystem.

Please see the updated datasheet for available RTC power modes. Although we have separated the VDDS and VDDS_RTC rails that allow for them to be powered independently in an RTC only mode, there could be power up sequencing issues that might not allow for an RTC only mode operation when using just the TPS65217C PMIC in the SiP (See https://e2e.ti.com/support/processors/f/791/t/497615 for more explanation and alternate implementation). We are testing several other alternate implementations of the RTC only mode and we will create an App note with respect to implementation. For now, using an external RTC module is your best bet.

The battery controller you linked should work. Note that V_CTRL needs to be always high to enable 1.8V LDO to power the RTC. VDDS would required a separate LDO that would come up in the correct sequence. Please see: http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf for the power up sequencing.

Best,

Neeraj

 

[Neeraj Dantu]

Hi Marcin,

We have followed up on this issue offline. Please look out for a schematic review providing input on the issue from our sales team.

Best,

Neeraj

[Neeraj Dantu]

Hi Hirogens,

The configuration described should work as MII1 and GPMC interfaces have no pins in common and pins shown in the figure can be used for SDIO interface.

Some resources that can help with pin multiplexing:

1. TI pinmux tool: https://dev.ti.com/pinmux/

2. Pin mapping between AM335x and OSD335x family: https://octavosystems.com/app_notes/osd335x-family-pin-assignments/

3. Device tree examples and building: https://github.com/RobertCNelson/dtb-rebuilder

Best,

Neeraj

[Neeraj Dantu]

The issue is probably related to EEPROM ID as you suspected. U-boot determines the flavor of the boards based on the EEPROM ID and selects the appropriate device tree for boot. It would be a good idea to check whether the device tree being selected is present at the right place in the root file system. Also, parse through the debug messages on UART0 to determine the exact point of failure. Here is a good resource on buildroot for build process and boot: https://bootlin.com/training/buildroot/

Please note that the forums at Beagleboard.org(https://beagleboard.org/discuss) are more appropriate for discussion and help on Beagle products.

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,,

Just to make sure, you have verified 24MHz oscillating crystal on the main OSC0 clock input?

As the issue is persisting, please send us your schematic and layout files for us for further debug. You can send them to our Business Development Manager at martin.burgos(at)octavosystems.com. You have communicated with him before.

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,

Can you check whether both your crystal oscillator(24MHz) as per this post: https://e2e.ti.com/support/processors/f/791/p/404843/1439658. Also regardless of internal pull-up, can you populate R4 and see if that fixes the issue?

Do you have more than 1 board that is exhibiting this behavior?

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,

If PMIC_PGOOD and PWRONRSTN are both at 1.8V, it means that the PMIC has successfully brought up all the power rails(See Figure 6 in http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf). The output of the buffer IC C1(RESET#) should be 3.3V(pull up). If you are seeing a 0V on this signal, it could mean that the buffer IC C1 is at fault. If C1 is faulty, replacing it should fix the problem. Another possible reason would be a short on the RESET# signal to GND (caused by layout).

Also, if R4 is not populated, it needs to be populated as the output of the buffer is open drain and WARMRSTN pin has a weak pull-up.

Let us know if that helps and if you have more questions.

Best,

Neeraj

[Neeraj Dantu]

Memaher,

USB OTG functionality can be enabled by exposing the USB_ID pin to the USB connector(instead of floating or pulling to GND).

In addition to USB_ID, special configuration is required to manage the power supply to and from the USB port in different configurations. If the port is functioning as a client port, power must be supplied to USB_VBUS+VIN_USB. If the port is functioning as a host, on board power switches should be enabled to supply power to the USB slave(done via USBx_DRVVBUS). The switching between the power in/out can be done using USB_ID(USB_ID controls USBx_DRVVBUS which can be used as enable signal to power out) and presence of VIN_USB as control signals.  If you are using a powered hub when using the port as a USB host, then no additional power configuration is necessary.

EDIT: Updating this to add info about USBx_DRVVBUS

Hope this helps,

Best,

Neeraj

 

• This reply was modified 6 years, 2 months ago by Neeraj Dantu. Reason: Add info about USBx_DRVVBUS

[Neeraj Dantu]

Andy,

Glad you could find the cause of the issue. Thanks for the documentation and closing the loop.

Best,

Neeraj

[Neeraj Dantu]

Andy,

To answer the question, yes the normal behavior is for the RTC subsystem to be powered on with the external oscillator.

I suspect what you are dealing with is a hardware issue with the 32KHz oscillator(It may have stopped working at some point after you probed last time?)

In order to make sure it is not a software issue, you can check/enable the external RTC crystal via software. If you look at “20.3.5.19 RTC_OSC_REG Register” in AM335x TRM(https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf), bit 3 of this register selects the clock source of the RTC subsystem. You can read this register to see if the external oscillator is selected as the clock source. You can do this read in Linux using the devmem2 utility (http://manpages.ubuntu.com/manpages/bionic/man1/devmem2.1.html). Using devmem2 should work as we used it for other register level access.

If you find that the external clock source is indeed not selected, you can enable bit 3 of the register to make that selection. Note that the RTC subsystem registers are write protected and you need to write 2 KICK registers in order to get write access to the registers. Please see: 20.3.5.23 KICK0R Register and 20.3.5.24 KICK1R Register in the AM335x TRM.

Other registers of interest include:

1. RTC_CTRL_REG

2. RTC_STATUS_REG

3. RTC_SYSCONFIG

4. RTC_PMIC

Hope this helps. Please let us know what you find.

Best,

Neeraj

 

[Neeraj Dantu]

Hey Andy,

If you don’t specify a device tree, by default the Bealgebone black device tree will be invoked (Along with some cape overlays depending on what is in uEnv.txt).

You can eliminate the device tree as the source of the error by using the Beaglebone Black device tree.

Instead of recompiling the whole kernel building the rtc_omap driver and inserting it in run-time can cut down on the debug effort here: https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L431. Adding debug messages to the ‘static void omap_rtc_poweroff’ function and dumping the registers of the RTC module along with the ‘struct rtc_time tm’ to somewhere in the SD card would help understand the state the module is in. The error is probably occurring in ‘static int tm2bcd()’ (https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L273) function.

Looking at the crystal, VIH and VIL for RTC_XTAL_IN are 0.65*VDDS_RTC and 0.35*VDDS_RTC. As long as the signal is oscillating across these two voltage levels, the signal is fine. However, there are specifications for the RTC oscillator circuit in “Figure 6-13. OSC1 (ZCZ Package) Crystal Circuit Schematic” (http://www.ti.com/lit/ds/symlink/am3358.pdf). You could try experimenting with values of C1 and C2 in the figure 6-13 of the datasheet.

Thanks for documenting the steps. Looking forward to the results.

Best,

Neeraj

 

[Neeraj Dantu]

Hey JF,

First addressing the custom board boot, do you have your EEPROM programmed with a Beagle compatible ID? Check: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/

There is an am335x_evm_norboot_defconfig (https://github.com/u-boot/u-boot/blob/master/configs/am335x_evm_norboot_defconfig) which has CONFIG_SPI_FLASH_WINBOND=y.

Try changing to CONFIG_SPI_FLASH_SPANSION=y and rebuild. The procedure to rebuild and replace the existing u-boot with the new u-boot is provided step-by-step here: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black. Specifically, you will need sections ‘ARM Cross Compiler: GCC’, ‘Bootloader: U-Boot’ and first 3 steps of ‘Set up MicroSD card’

 

[Neeraj Dantu]

Hey JF,

 

Did you populate J11 to complete the electrical connections between the SPI NOR and the AM335x SPI interface? The first step would be to verify the electrical connectivity and monitor whether the communication signals are reaching the NOR flash. Once you have verified the connectivity, verifying the communication between the AM335x and the NOR flash via for example, spidev on Linux would be the next thing to do. Scoping the interface pins including for whether the chip select pin is going low, the clock is being exercised and the data is being transferred via D0 and D1 would also narrow down where the issue is.

The OSD335x integrates and exposes all the peripheral functions of the AM335x processor (Except for internal DDR). So, all the defconfigs that work with the AM335x processor should also work for OSD335x.

[Neeraj Dantu]

Andy,

While we have not used it ourselves, the DP83867 is a good candidate for a Gigabit Ethernet PHY. You can find a reference design that integrates the DP83867 and AM335x here:http://www.ti.com/tool/TIDA-00204#technicaldocuments. Documentation: http://www.ti.com/lit/ug/tidu832b/tidu832b.pdf

The schematics are also available: http://www.ti.com/lit/df/tidrdr0a/tidrdr0a.pdf

Note that AM335x supports MII, RMII and RGMII interfaces. There are other devices from Microchip(https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1635) that have good Linux support.

Best regards,

Neeraj

 

 

[Author]

Posts