[Neeraj Dantu]

Thanks Stefan! We will forward your feedback.

Best,

Neeraj

[Neeraj Dantu]

Willis,

There was most likely an issue with a driver instantiation or peripheral definition in the device tree overlay.

If you have a USB to UART converter cable, you can use a serial terminal application like Putty on your computer to look at the boot messages and determine where the board is getting stuck.

The procedure to boot from the SD card interface and flash the eMMC is described in https://octavosystems.com/forums/topic/flash-the-emmc-of-the-octavo-red/. If you want to recover from the error with the device tree overlay without loosing your files in the eMMC, you would have to boot from the SD card, mount the eMMC and edit the boot/uEnv.txt file to disable the problematic device tree overlay by commenting the line in which it is assigned to uboot_overlay_addrx.

Hope that helps.

Best,

Neeraj

[Neeraj Dantu]

Hey Willis,

The image is available on the RED board web page: https://octavosystems.com/octavo_products/osd3358-sm-red/

As you mentioned, you can flash the image onto an SD card and boot the board from the SD card. Additionally, you can flash the eMMC by un-commenting the last line in /boot/uEnv.txt(cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) which initiates a flasher script.

Best,

Neeraj

 

[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

[Author]

Posts