[Neeraj Kumar Reddy 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, 5 months ago by Neeraj Kumar Reddy Dantu. Reason: Add info about USBx_DRVVBUS

[Neeraj Kumar Reddy Dantu]

Andy,

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

Best,

Neeraj

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

 

 

[Neeraj Kumar Reddy Dantu]

Andy,

Please use the version of the kernel that you are currently working with.

As mentioned earlier, you can build a Beagle image by following the steps in https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black

You can also use build environments like Buildroot and Yocto to make custom images. Buildroot is the easier option. Both of them have extensive documentation and support for AM335x. Take a look at https://e-ale.org/elc2018/ for a start.

If you programmed your EEPROM after booting up, you will not need to have the patched version of u-boot. So, you can try upgrading the bootloader to see if there is an initialization issue for the RTC subsystem.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Andy,

Please see https://groups.google.com/forum/#!topic/rtc-linux/yKfIpoD5gRI for the power off procedure. The RTC module is responsible for turning off the PMIC and shutting itself off.

You could add some debug statements to omap_rtc_power_off function: https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L431  to get more information about what is happening.

Please also see: https://groups.google.com/forum/#!msg/beagleboard/_vZba5Qu1FY/ezoF_EsfBAAJ. May be worth a try to set the RTC module to use internal clock.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Andy,

Please check the interface between PMIC and AM335x is correct in your system. You can compare the connections on your board to those in OSD3358-SM-RED(Design files available here): https://octavosystems.com/octavo_products/osd3358-sm-red/.

Do you have the 32KHz oscillator for the RTC subsystem on your board? If so, please verify that there is a proper 32KHz clock input to the OSD335x from the oscillator. Similar issue resolved as faulty oscillator: https://e2e.ti.com/support/processors/f/791/t/612270?Linux-TPS65910-Kernel-panic-at-shutdown#pi239031349=3

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

The name of the product is: Sabrent USB-SBCV USB 2.0 Sound Card – Stereo

Here is a link to the project: https://beagleboard.org/p/beaglefriends-octavosystems/adding-text-to-speech-to-pocketbeagle-projects-3ab078

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Hey Andy,

The McASP subsystem supports multiple channel outputs and is able to interface with different kinds of audio codecs. Please see(TI BSP): http://processors.wiki.ti.com/index.php/AM335x_Audio_Driver%27s_Guide. TI has several audio codecs that can work: http://www.ti.com/audio-ic/converters/codec/products.html#p1339=2;2.

Also take a look at BELA: https://github.com/BelaPlatform/Bela/wiki. It is a platform designed to be used for audio applications.

We have used USB audio cards in our projects before. They are a good way to go and definitely requiring the least amount of effort. The ALSA subsystem will be able to maintain route multiple audio channels for you. Couple of resources you could look at:

https://www.alsa-project.org/main/index.php/Documentation

https://www.tldp.org/HOWTO/pdf/Alsa-sound.pdf

Best,

Neeraj

 

[Neeraj Kumar Reddy Dantu]

Mario,

pruss-rproc: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx-pruss-rproc.dtsi

Will fix the repo. Thanks for pointing out!

Neeraj

[Neeraj Kumar Reddy Dantu]

These are Ferrite beads that help with noise reduction on the power rail. The values depend on the board and are chosen as needed. For this particular board, we used the following components:

FB1: MPZ2012S601AT000
FB2: BLM21AG151SN1D

Hope that helps.

Best,
Neeraj

[Neeraj Kumar Reddy Dantu]

Andy,

Can you use an newer Beagle image to boot the board and see if that fixes the issue? There might be one bad process that is hanging when it is closing and that might be causing the panic. A newer kernel could have patched the bug that is causing the panic.

If you do not have a display in your system, the IOT images from Beagle’s page: https://beagleboard.org/latest-images will work better because all the GUI applications and processes are removed.

You can also build your own image. Here is a procedure to building a Beagle image: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black

Best,

Neeraj

[Author]

Posts