Beko,
We don’t expect any issues with connecting VIN_BAT and PMIC_BAT_SENSE to GND via 1K resistor.
Please let us know if you have more questions.
Best,
Neeraj
Olmo,
Here are some inputs on your questions:
1. The Beagle U-Boot does not setup ethernet well. This does not effect the kernel configuration though. I would suggest you follow the below procedure to get Ethernet working in U-Boot:
2. Yes, EEPROM ID is responsible for selecting the device tree with which the board will boot. We would suggest you try the RED board image linked here: https://octavosystems.com/octavo_products/osd3358-sm-red/#Software as it has been verified to be working with the RED. Also note that your PHY address would also have to match the RED board in order for it to work.
3. The EEPROM ID is bypassed in OSD3358-SM-RED image and device tree is selected using /boot/uEnv.txt (dtb=). On Beagle images RED board ID ends with OS00. Note that latest Beagle images have not been verified to work on the RED board.
4. The kernel log you have attached does not show all the kernel messages. Output of dmesg command could give us better understanding of what is going on. We suggest the following steps as to debug:
– Use the OSD3358-SM-RED image to boot the board and look at ethernet related logs in the output of dmesg
– Use the above procedure(in #1) to fix U-boot and get Ethernet to work in U-Boot. This procedure has been verified to be working on the RED board.
Besst,
Neeraj
Hey Beko,
OSD335x_BAS cannot support RTC only mode. So, you will not able to use a coin cell battery to power the RTC subsystem to keep time.
However, as you suggested, you can use an external battery powered RTC to keep time and generate alarms if you need.
We suggest the following:
1. Use the external RTC powered by a back-up battery and connect to OSD335x as needed.
2. Use 3.3V of the OSD335x output to pull-up the I2C lines to avoid any pull-up when OSD335x is not powered.
3. Keep the RTC subsystem of OSD335x ON by configuring the device as shown in the reference design: https://octavosystems.com/octavo_products/osd3358-sm-red/. This will allow U-boot and SPL to not encounter errors during boot up initialization. See https://octavosystems.com/forums/topic/osd335x-c-sip-bootloader-issues/ for more information on the issues that are encountered when RTC subsystem is powered off.
Please let us know if you need any more help.
Best,
Neeraj
Beko,
Unfortunately, AM335x does not support USB boot in host mode. As described in section 26.1.9.6 in AM335x Technical Reference Manual(http://www.ti.com/lit/ug/spruh73q/spruh73q.pdf), USB boot is only possible via a virtual Ethernet interface on USB0 functioning as a client port. In addition, SYSBOOT pins need to be configured as shown in table 26-7 of the reference manual. So, it is not possible to use a regular flash drive to boot the device.
Please let us know if you have more questions.
Best,
Neeraj
Hey Steve,
Apologies for the delayed response. Since the same Linux image does boot and works well on the RED board, we assume it is a hardware issue barring 1 last thing for you to try: Add RED board’s EEPROM ID according to this application note on your custom board: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/.
We would like to take a look at the layout of the board. Can you contact our sales lead: Martin Burgos: martin.burgos(at)octavosystems(dot)com so we can set up a communication channel.
Best,
Neeraj
Steve,
To answer the questions, the bootlog is reporting the USB host controller and VIN_USB is not needed for USB operation. Here are a couple things you can try:
1. Can you post the kernel log messages(dmesg output) after inserting a USB device into the board?
2. Can you try a pre-built image from Beagleboard.org: https://beagleboard.org/latest-images which are known good images for working USB host configuration.
Best,
Neeraj
Steve,
One more thing to verify is the signal integrity of the USB data lines. Please make sure you have length and impedance matched USB data lines as well as this could effect the signal integrity of the differential USB data signal.
best,
Neeraj
Steve,
The circuit looks fine. From your bootlogs, it looks like USB host device is coming up. A couple of things to check:
1. Power and voltage requirements for the slave device: The switch will only be able to supply 500mA. Please make sure this is okay in case you are trying to use 2 slave devices or using a device with higher current requirements. Please also make sure that the voltage on VBUS pin is higher than VBUS threshold when the device is plugged in and consuming power. One more debug step would be to look whether there is a brownout during the inrush stage when the device is plugged in.
2. Please make sure you have the appropriate driver built into the kernel. The bootlogs indicate that a slave device is detected. But, does not identify the device.
Please let us know if you have more questions.
Best,
Neeraj
Steve,
Thanks for the update. The bootlogyou attached looks good. We will respond to the USB issue on the post.
Best,
Neeraj
Alvaro,
If you programmed the board ID with the one described in the application note(OS00), the board should boot and start a USB RNDIS (Ethernet over USB) interface. This interface should be named ‘usb0’ and should show up on the interfaces list.
If you use a USB cable to connect the micro USB port of the board to your computer, you should be able to ping the board via this RNDIS interface. If you are unable to, it may be because of the computer was not assigned the right IP address. You can set the IP address of your computer’s network adapter by modifying the IPV4 address settings in the properties of the Ethernet adapter created by the connection to the board.
The second error that you are referring to in your post shows that an Ethernet PHY has not been detected at the right address. This PHY corresponds to the Ethernet interface and is not related to the USB interface. So, if you don’t have an Ethernet interface on your board, you should disregard the error for now. Note that you will have to change your device tree later to reflect the hardware present on your board.
Please let us know if you have any more questions.
Best,
Neeraj
Alvaro,
Try executing the following scripts on the RED image:
./opt/scripts/boot/am335x_evm.sh
./opt/scripts/boot/autoconfigure_usb0.sh
Best,
Neeraj
JP,
VDDS_RTC is the power supply for the RTC subsystem. This power rail needs to be powered by a 1.8V power rail whether RTC subsystem is to be used or not. So, not connecting VDDS, VDDS_RTC to SYS_RTC_1P8V is most likely the cause for the board not booting. See section 6 (Power and Clocking) of AM335x datasheet for more information on the boot process and VDDS_RTC’s role: http://www.ti.com/lit/ds/symlink/am3358.pdf
We recommend using the same circuit configuration as the SM-RED board for RTC subsystem, as it is the easiest to bring up.
Please go through the following resources so you can catch everything that needs to be changed for the next revision:
1. Schematic checklist: https://octavosystems.com/app_notes/osd335x-schematic-checklist-am335x/
2. OSD335x C-SiP reference design: https://octavosystems.com/docs/osd3358-sm-red-c-sip-schematics-pdf/
Best,
Neeraj
Sktz,
The first thing to do here is to verify whether the design is correct. Please review your Ethernet design and/or post it here or contact us through the support channel for a review on it. See https://e2e.ti.com/support/interface/f/138/t/694453 for a design to compare against.
Please post the kernel logs of various fail cases so we can see where the fault occurs in initialization. For example, it could be that the pull-up/down configuration on the PHY address pins are not configured properly and the processor detects the PHY at a different address than what is set in the device tree.
Another possibility is that there could be EMI causing signal interference issues on your design. Take a look at this useful reference for layout guidelines on Ethernet: https://resources.pcb.cadence.com/blog/2019-mii-and-rmii-routing-guidelines-for-ethernet
Please let us know if you have any more questions.
Best,
Neeraj
Great!
Thanks for letting us know.
Best,
Neeraj
Madhu,
One thing to make sure is the T_rise_time of the PMIC. The TPS65217C(http://www.ti.com/lit/ds/symlink/tps65217.pdf) requires the input voltage to go from 100mV to 4.5V with in 50ms.
Can you try a different bench power supply with a shorter rise time to make sure that is not the issue?
As you can see in Figure 11 of the datasheet, switching transistors are responsible for switching the power input between VIN_AC and VIN_USB. The SYS rail then powers the rest of the DC/DC converters and LDOs. So, there should be no difference in behavior of these two power rails except for inrush(inrush on VIN_USB can be limited to 500mA. Inrush on VIN_AC can go as high as 1.5A).
You can also dig in a little more and analyze the power up to see where the fault occurs. See https://octavosystems.com/app_notes/osd335x-sm-power-application-note/ for power up sequencing.
Best,
Neeraj
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields