[Erik Welsh]

Yes, the ZCZ variant of the AM3358 is used in all of the Octavo OSD335x Family of devices.  The reason the second part of the second line is very different between the two devices is that the manufacturer of the devices changed.  However, the design itself is the same and we have had many customers switch seamlessly between the OSD3358-512M-ISM and OSD3358-1G-ISM devices.

Please note that these devices are sensitive to moisture and all of the MSL guidelines spelled out in the datasheet (see Section 9.3) must be followed to ensure no issues during manufacturing.  Can you provide more information about the failures you are seeing on VDDSHV2?  If you are not able to do this publicly, then please send the information to support [at] octavosystems.com and we can discuss the information privately.

 

 

 

 

 

 

[Erik Welsh]

I apologize.  There was a bounce-back on the email.  You should have received an email by now.  If you have not, please reach out to sales [at] octavosystems.com so we can get your correct email.

[Erik Welsh]

We will answer this question through our sales support channel.

[Erik Welsh]

Scott,

Yes.  I apologize for the confusion.  I should have said OSD3358-C-SIP-RED.  The statement about the eMMC reset not being in the device tree applies to both of the designs.

Thanks,

Erik

 

[Erik Welsh]

Scott,

Yes, you can do a direct connection between the eMMC_RSTN and GPMC_A4.  Please note that the eMMC reset is not defined in the default device tree for either the OSD3358-SM-RED or other designs from BeagleBoard.org(TM), so you would need to define it if you would like to use that functionality.  Additionally, depending on the pins you have used in the rest of the design, we would suggest choosing a pin that has a reset release state of “H” instead of “L”.  This will reduce your power consumption a little since the AM335x pull resistor will not be pulling against the internal pull up resistor to pull up the eMMC_RSTN signal.

Thanks,

Erik

[Erik Welsh]

When running at 70C ambient, what is the case temperature that was observed?  The OSD3358-512M-BCB is rated to 85C case temperature.  From your description, it sounds like the second power up is not being detected.  This could be due to some of the components being outside of the thermal spec.  If you place the unpowered unit in the chamber, soak the device at 70C, and then try to start up the device, do you see any issues?

Thanks,

Erik

 

[Erik Welsh]

Jennifer,

Yes, you can write custom programs on the AM335x that do not use Linux. The biggest issue is all of the system initialization that is required to get the processor and DDR up and running.  There are a couple of paths to follow:

1) You can use the TI StarterWare:  https://processors.wiki.ti.com/index.php/StarterWare  While you don’t necessarily need U-Boot, you can see an example of using U-Boot to load a StarerWare program in our application note:  https://octavosystems.com/app_notes/bare-metal-on-osd335x-using-u-boot/  However, please note that TI no longer supports this software package.

2) You can use the TI-RTOS:  https://www.ti.com/tool/PROCESSOR-SDK-AM335X  This includes boot loaders and boot utilities.

You can prototype this development on the OSD3358-SM-RED.  However, you might want to get a JTAG debugger and populate the JTAG header to make it easier to interface with Code Composer Studio.

Please let us know if you have any additional questions.

Thanks,

Erik

[Erik Welsh]

TJ,

Are you planning to use a LiPo battery or were you trying to drive the VIN_BAT input with a regulated 3.3V supply?

I would suggest that you use one of the development platforms (such as the OSD3358-SM-RED) to prototype this operation.  All of the pins you need are brought to headers (i.e. the VIN_BAT input and additional battery pins are brought to thru-hole pins next to the 5V power input jack).  When using the battery input, there are some power up considerations.  You will need to independently generate a start up condition using the PB_IN pin.  See the TPS65217 datasheet for more information.

Please let us know if you have an additional questions.

Thanks,

Erik

 

[Erik Welsh]

Gavin,

If you look at Note 2 on page 1 of the DM3BT-DSF-PEJS Micro SD Card datasheet, you can see that there is a Card detection switch (B) that corresponds to this pad on the symbol.  On the footprint, the card detection pad is the slightly smaller rectangle in the upper right corner.  If you extract the library from the Eagle schematics, you can check the pad names and mapping for the device.

Please let us know if you have any additional questions.

Thanks,

Erik

 

[Erik Welsh]

For both the OSD335x and OSD32MP1 families, we do not recommend series termination resistors on the USB data lines.

Thanks,

Erik

[Erik Welsh]

We apologize for the delay in responding to this question.  Were you able to get this resolved or is this still an issue?

To give some background on this, there is a hardware watchdog timer within the AM335x core.  That hardware watchdog timer is what comes up in /dev/watchdog.  You can see a tutorial on how to use it here:  https://www.onlogic.com/company/io-hub/tutorial-using-beaglebone-black-watchdog-timer/

Now, to get the GPIO watchdog timer working within Linux, there are two things:  First, you need to make sure that the gpio_wdt module is enabled and is part of the kernel.  We would suggest, that you take a look at https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black and follow the instructions on building the kernel to see what modules are enabled.  If you search for “WATCHDOG” in the kernel config, you should be able to see what is enabled.

Additionally, there could be a pinmuxing issue in that the pin is not configured as a GPIO.  Please take a look at your device tree and see if pin gpio3 17 is used/configured anywhere else.

Please let us know if you have any additional questions.

 

 

 

 

[Erik Welsh]

Alberto,

Thanks for bringing this to our attention.  We have successfully run the OSD32MP1 on the latest ST Developer Package.  However, we have not yet updated the tutorial to reflect this.  We will update the tutorial documentation in the next couple weeks.

If you have any other specific questions, please let us know.

Thanks,

Erik

 

[Erik Welsh]

Farzin,

The PRUs run at 200MHz.  You might be able to get data into the AM335x at 600Mbps but it will be difficult to do anything with that data.  You would need to do very little processing and use very low level code.  It would be better if you implemented a portion of your algorithm in the FPGA to get the data rate to the AM335x down (i.e. transfer “information” instead of “data”).

Thanks,

Erik

 

[Erik Welsh]

Farzin,

What data rate are you trying to support?

The PocketBealge headers provide access to a number of interfaces, including the PRU, which can be used to transfer data into the AM335x processor.

Thanks,

Erik

 

[Erik Welsh]

We apologize for the confusion.  Both the datasheet and the Altium footprint are correct.

If you look at the datasheet, you can see that the letters run from left to right and the numbers run from bottom to top when viewed from the top (i.e. A1 is in the lower left corner and Y20 is in the upper right corner).  If you look at the Altium footprint, you can see that the letters run from top to bottom and the numbers run from left to right when viewed from the top (i.e. A1 is in the upper left corner and Y20 is in the lower right corner).  This indicates that the Altium footprint is rotated 90 degrees clockwise from the datasheet.

This is the same behavior for the Altium footprint for the OSD335x-SM.

Thanks for pointing this out.  We will resolve the confusion with the next revision of the library.

 

 

[Author]

Posts