[Neeraj Dantu]

Aleix,

From your latest post, it does look like it is not an EEPROM ID issue.

Given that you are able to verify that the MMC interface works and you are able to get to U-Boot and rebuild it, you can try and narrow down the exact location in U-Boot that the board is getting stuck at. This could help determine whether there is an issue with the PMIC/DDR interfaces or whether it is a software issue.

You can see board detect function is being called from here: http://git.denx.de/?p=u-boot.git;a=blob_plain;f=arch/arm/mach-omap2/am33xx/board.c;hb=HEAD. Putting some debug messages in this file to print on the UART console might help pin pointing the location of the fault.

We hope that helps. Please let us know if you have any update on this.

Best,

Neeraj

[Neeraj Dantu]

Thanks for the detailed analysis of the clamping circuit.  We agree that this is probably not the most ideal clamping circuit.  However, it should be good enough to accomplish its design goals.  The AM335x requires that if the VDDS and the VDDSHVx input voltage rails are ramping down simultaneously then the voltage difference between these rails should be within 2V of each other or there could be some slight damage to the IO circuits which could over time result in reliability issues (see Section 6.1.2 of the AM335x datasheet).  

 

  During power down, the TPS65217C cannot guarantee this condition since it cannot control the loading on the power output rails.  The TPS65217C will shut off LDO4 (SYS_VDD3_3P3V on the OSD335x-SM, which is generally used to power the VDDSHVx inputs) at STROBE 4 which is is much earlier than LDO1 (SYS_RTC_1P8V on the OSD335x-SM, which is generally used to power VDDS) at STROBE 15.  However, it cannot guarantee the down power ramps of each rail and therefore, the clamping circuit is a precaution against violating the 2V requirement.  Given that each rail is being powered down, the currents involved to keep the difference between the voltage rails < 2V should be small.  Additionally, there are many situations where there is no need at all for the clamping circuit.  

 

  The clamping circuit itself was developed by Texas Instruments (see http://www.ti.com/lit/ug/slvu731b/slvu731b.pdf Section 5) and used in the reference designs for the OSD335x to showcase the most robust design possible for our customers.  In general, we recommend customers putting down the footprints for the clamping circuit during prototyping and test if it is necessary to populate the clamping circuit for production.  If you have a better recommendation for the clamping circuit, please let us know so that we can add that to our discussion of the clamping circuit.  Again, thank you for digging into this, please let us know if you have any additional questions and we look forward to working with you on your design.

[Neeraj Dantu]

Hey Aleix,

1. There are several methods described in the app note that deal with the EEPROM. The ID can be hard coded as described in 4.1. U-boot can be patched to recognize a blank EEPROM as described in 4.2(Note that EEPROM needs to be blank for this method to work. A corrupted EEPROM ID will not work). You can also program the ID outside u-boot as described in section 6.

One additional thing to note is that the version of u-boot used in the app note is v2018.03. No UART output in general indicates that U-Boot was not updated. Please verify that you are updating the u-boot correctly as described in https://eewiki.net/display/linuxonarm/BeagleBone+Black(under “Setup microSD card”).

2. Yes, this verifies that you have a working SD card interface!

3. We are assuming you coded the board ID “..A335BNLTOS00” . This board ID was created a while after the 7.5 image was released. So, that image will not recognize a board with ID ending with OS00. If you code the board with beaglebone Black ID: “..A335BNLT00C0”, which was a valid ID for image version 7.5, you should be able to boot the board normally. For EEPROM IDs, please refer to: https://github.com/beagleboard/image-builder

4. We have not tried this approach, but note that booting via UART can be susceptible to data transfer issues. Please review the information above and let us know if you have any specific questions.

We are available on this forum and will be happy to help.

Best,

Neeraj

 

[Neeraj Dantu]

Sh,

TLVH431 controls the state of transistor Q1 being ON/OFF. The reference voltage input to TLVH431 is established by the voltage divider comprised of R40 and R41. The voltage divider makes it such that if the voltage difference between VDDSHV_3P3V and SYS_RTC_1P8V is > 1.55V, the reference voltage threshold of TLVH431 of 1.24V is met at it’s VREF input(Node A). This changes voltage at node B(base of Q1) turning transistor ON/OFF based on TLVH431 turning ON/OFF. Note that the voltage divider(R40 and R41) controls the threshold voltage here.

Please let us know if you have further questions.

Best,

Neeraj

[Neeraj Dantu]

sh,

In theory, the mixing of figures 1 and 2 in your circuit seems reasonable. Not connecting BAT_SENSE to BAT might cause power up issues, but the PMIC should at least try to bring up the power rails.

Another signal you can check is the PMIC_NRESET which if grounded could be causing the PMIC to be in RESET.

SYS_VOUT is the power supply input for the LDOs and DCDC converters in the PMIC(https://octavosystems.com/app_notes/osd335x-sm-power-application-note/). So, a short on this rail could also be causing the power rails to not come up. It is unfortunate that you do not have access to this rail.

One more thing to verify is the footprint for the OSD335x-SM being used. Please make sure all the pin names are correct and they are in the correct positions.

As mentioned earlier, pre-bake and reflow profile are additional avenues to investigate.

Please let us know if that helps or if you have an update.

Best,

Neeraj

[Neeraj Dantu]

Thanks for the update! Happy to help

Neeraj

[Neeraj Dantu]

Hi ashare,

Apologies for the confusion. Section 4 offers 2 methods for bypassing the EEPROM check. In 4.1, it is shown to be done by changing the contents of the function “board_is_bone_lt”. In section 4.2, the patches you referred to are used. I was referring to the hard-coding method described in section 4.1.

If you are using the patched version of u-boot, the function “board_is_blank_bone_lt()” in  https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch should return true. Going through this function, it looks like there is a check on whether the EEPROM interface is working. If the check returns false, u-boot might not be able to advance to the board initialization. In addition to that, you mentioned that you encountered a failure in the middle of the programming of the EEPROM. At this point, this is just a theory. If you can try the hard coding method described in section 4.1, we should be able to find out whether this is the failure point.

We have not encountered an issue like this before. It’s important to keep in mind that this is a theory based on u-boot behavior and there might be something else causing the issue. Please let us know how your debugging efforts go!

Best,

Neeraj

[Neeraj Dantu]

Hey ashare,

One possibility is a non functional I2C interface between the processor and the EEPROM. The applied patch linked above checks if the EEPROM is dead(https://github.com/trini/u-boot/blob/master/board/ti/common/board_detect.c#L287) and that might be causing u-boot to not detect the board as a blank EEPROM board. You could bypass the check in the function by hard-coding the board detection process as shown in section 4 of the EEPROM App note(https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/).

You can also try a readily available blank image from https://rcn-ee.com/rootfs/bb.org/testing/2018-10-07/stretch-iot/.

Please let us know if that helps or if you have more questions.

Best,

Neeraj

[Neeraj Dantu]

Hey sh,

Given your description of the behavior, there could be more than one reasons for the failure. As you mentioned, please make sure that the power rails are not shorted. SYS_VOUT powers the SYS_RTC_1P8V LDO. So, checking SYS_VOUT is a good first step. Apart from that, please go through the schematic checklist(https://octavosystems.com/app_notes/osd335x-schematic-checklist/) for any other potential issues with the design.

Other reasons for the part not booting up could be bad reflow profile, part orientation or not pre-baking the parts.

How many boards have you verified to have this fault condition?

Best,

Neeraj

[Neeraj Dantu]

Roman,

U15(TPS2051) provides power to the USB devices. You can see that the output of this chip connects to the VBUS lines of each of the USB ports. This power switch is enabled by USB1_DRVVBUS signal of the USB1 peripheral controlled by the OS.

Please let us know if you have more questions.

Best,

Neeraj

[Neeraj Dantu]

Stefan,

The schematic and layout look fine. Here are some thing you can look at:

1. Please verify that the RESET signal for the eMMC(EMMC_RSTN) signal is pulled up to 3.3V and eMMC is not in reset during operation

2. Is R89 populated?

3. Please verify the orientation of the eMMC device

As you are trying to interact with the eMMC over u-boot, device tree does not come into play. The u-boot on RED board image should be able to communicate with the eMMC just fine.

Did you program a board ID to EEPROM(https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/)?

We would suggest you boot from the SD card interface and look at the output of ‘lsblk’ also to see if Linux is able to detect the eMMC. Please let us know how the debug goes.

Best,

Neeraj

[Neeraj Dantu]

rfiller73,

1) Yes, SYS_VDD2_3P3V and SYS_VDD3_3P3V can be used to power external circuitry. However, you will have to make sure to keep the current consumption on these rails under the maximum current limits in Table 8.2 of the datasheet(https://octavosystems.com/docs/osd335x-sm-datasheet/)

2) As mentioned above, the components can be powered using SYS_VDD2_3P3V and SYS_VDD3_3P3V as far as the total current on the power rails are less than the maximum output current specified in the above referenced table.

Best,

Neeraj

[Neeraj Dantu]

Hey MC,

There are a couple of ways to approach the issue. First, from what we understand, you have a BBB with a working Linux image that loads the correct drivers. In order to reproduce the exact same system on the custom board, please make sure of the following.

1. Switch the EEPROM ID from what is currently programmed to the BBB EEPROM ID which is currently programmed in the BBB so that same initialization is done on both boards. See https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/ for ways to program the EEPROM

2. Make sure the u-boot version and the boot source are the same on the custom board and the BBB. This may require you to extract the image in the BBB to an SD card and boot with the SD card on both the boards and compare the boot logs(including u-boot logs)

Secondly, from http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver, it seems that the 2 changes that need to happen to use the 8250 driver instead of the omap serial are the change from ‘ttyO0’ to ‘ttyS0’ in u-boot and changing the kernel configuration to disable ‘omap serial port support’ and enable the internal 8250 drivers.

If the custom board you are booting is not booting from the same u-boot as BBB, that might be causing the incorrect loading of the driver. On the kernel level, make sure that you have the ‘omap serial port support’ disabled in your kernel configuration as it looks like these drivers are being loaded in the boot log attached.

Note that from boot log, the 8250 driver is being loaded: “[    0.498287] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled”, but the omap driver is taking precedence? (not sure) Disabling the omap driver could resolve this as discussed.

Best,

Neeraj

[Neeraj Dantu]

Hey Mr.Current,

Two files, refdesign.dts and OCTAVO_OUTPUT can’t be accessed because “This file type is not permitted for security reasons”. Can you please re-upload with a different name or ZIP them?

As for the issue, note that because of the EEPROM ID check in u-boot, different boards can go through different initializations that includes pin-multiplexing. Please make sure you have UART1 pin multiplexing in your device tree in the ‘am33xx_pinmux’ node. Also, please post the output of ‘cat /proc/device-tree/ocp/serial@58022000/status shows’

Best,

Neeraj

[Neeraj Dantu]

olmoDalco,

Not connecting to an existing network with a verified Linux image indicates an issue with either the design or layout.

Since you mentioned that the Etehrnet interface design is the same as the OSD3358-SM-RED, we are assuming:

1. The same interface pins of OSD335x-SM were used in your design

2. The same configurations are set on the PHY

One thing to look at is the Ethernet connector. If you are not using the same ethernet connector as OSD3358-SM-RED, please verify the magnetics configuration is the same as on the OSD3358-SM-RED.

If you still cannot resolve the issue, we will have to take a closer look at your design. Please contact our sales and business development (martin.burgos(at)octavosystems.com) for further offline discussions.

[Author]

Posts