FAQs

Please come to our contact page and chose “Add to mailing list” in the Request Type pull-down menu.  Stay informed with our quarterly newsletter along with special announcements such as datasheet updates.

No, it won’t. We specifically designed our products to have a wide 1.27 mm ball pitch allowing the use of low cost manufacturing options.

TI is a key supplier to Octavo.  We have a very strong partnership but there are no financial ties between us.

You can purchase all of our products from our Distribution partners.  They are listed on our Buy Now page.

In our lab, we have used both the XDS110 and XDS200 emulators.  Depending on your emulation / debug needs, you can also use higher end emulators like the XDS560v2.

If you plan to use debug features like trace that are available on higher end emulators, please make sure that you bring the EMU2/EMU3/EMU4 pins to the JTAG header. If you do not plan to use those higher end debug features, then those particular EMU signals do not need to be routed to the JTAG header.

Texas Instruments also provides a number of different websites detailing information about the emulators that can be use with the AM335x processor, and thus the OSD335x SiP, as well as general inofrmaton about JTAG connectors and adapters:

• Debug Probe Performance Comparison
• XDS Target Connection Guide
• JTAG Connectors
• JTAG Adapters

Linux images from Bealgeboard.org require EEPROM to be programmed with a board ID. The following solutions can be used to overcome this issue:

1. Bypass the checks in the bootloader (u-boot)

2. Use Robert Nelson’s patch to create u-boot that will boot and allow you to program the EEPROM: In u-boot apply the patch:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch#L157-L164

u-boot also uses a device tree that you might need to modify. You should find the u-boot device tress in ./arch/arm/dts It is useful to look through the 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch from Robert Nelson (see https://eewiki.net/display/linuxonarm/BeagleBone+Black) since this patch modifies device trees and can point you to important directories in u-boot.

A more detailed explanation of the above options can be found in this forum post.

Generally, XDS200 connectivity issues can be resolved by updating its firmware.

To update a XDS200-class JTAG debugger connected via USB, using a Windows host is highly recommended. Close any instances of CCS that are running in your system. Open a Windows Command Prompt and issue the following commands:

1. Go to the directory where the utility is installed:

C:\>cd C:\ti\ccsv6\ccs_base\common\uscif\xds2xx

2. Run the configuration just to make sure a XDS200-class debugger is connected and to confirm the firmware revision installed on it:

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0

3. If you have a single XDS200 connected via USB:

Run the following commands in the exact order shown below (the batch file update_xds2xx does this in reverse order, increasing the chances of failure):

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf update xds2xxu 0 xds200_firmware_v1008.bin

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf program xds2xxu 0 xds200_cpld_v1008.xsvf

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf boot xds2xxu 0

4. After that, run the command in step 2 again to check if the correct firmware was loaded.

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0

If connectivity issues persist, please go through the XDS200 Wiki to find out more information.

The OSD335x is BeagleBoard Compatible meaning they can run any of the software provided by BeagleBoard.org. Here is a link to getting started on Beaglebone.

The AM335x Software Design Guide from TI will help you become familiar with the overall software design process for AM335x. TI also provides Linux and TI-RTOS support for software development.

The ORCAD files for both OSD335x and OSD335x-SM devices can be found here.

Yes, OSD335x family runs all Linux distributions supported by TI for AM335x. It is also officially BeagleBoard Compatible so it will run the same Linux distributions found on Beaglebone Family of products.

Here are some good resources:

Texas Instruments Linux Kernel Users Guide

elinux – Building BeagleBone Black Linux kernel

Beyond Logic – Compiling the BeagleBone Black kernel

elinux – BeagleBone Black Debain

These power pins are driven by the TPS65217C PMIC and are used internally to power the AM335x, DDR and other components.  These pins are all connected within the SiP and should not be connected externally.  Optionally, these pins can be brought out as test points for debugging purposes only.  They should NEVER be used to power external components.

The following table shows the minimum set of signals that need to be connected externally between the processor (AM335x) and PMIC (TPS65217C) to use the OSD335x-BAS/IND devices. It also shows internal pull up resistor values, the voltage rail they are pulled up to and the specific pad that was pulled up.

Power consumption of OSD335x depends highly on usage scenarios. The OSD335x-BAS/IND Power Application Note and Software Power Management with the OSD335x Family application notes will give you detailed information about OSD335x power consumption in various operating states.

Other helpful resources  are:

1. AM335x Power Consumption Summary: This wiki page provides current and power measurements for common system application usage scenarios. However, these measurements were made for a presently unsupported version of SDK. Updated power consumption data can be found here.
2. Power Estimation Tool: This entails modifying and submitting a spreadsheet specifying processor mode and peripheral usage of AM335x. Login to TI website is required and the results will be emailed to the email address used to login.

The OSD335x family supports all the frequencies supported by corresponding AM335x present inside. For example, the AM3358 inside the OSD3358 supports 6 Operational Performance Points(OPP). It can run at 300MHz, 600MHz, 720MHz, 800Mhz and 1GHz. These operational performance points are set using the Digital Phase Locked Loops(DPLLs) and MPU, CORE voltages on the AM335x. The following figure from the AM335x datasheet (Table 5-7) shows the OPPs, the corresponding MPU voltage to be set and the frequency of operation of the OPP (Source: AM335x datasheet).

The oscillator circuit for real time and system clock inputs is shown in figure 6-9 and 6-12 in the AM335x datasheet.

The values of components C₁ and C₂ referred in the figures depend on the load capacitance (C_L) specified (more…)

Yes we do. You can find the OSD335x Family Pin Assignments table here.

The ball map of the OSD335x-BAS/IND was designed to match the ball map of AM335x ZCZ package except for a few changes. The following figure highlights the changes that were made to AM335x ZCZ ball map.

Violet and Grey pins are the only pins that have been moved or functionally changed.

Blue pins (AM335x DDR interface) should be left unconnected.

Green pins (AM335x Power input pins) should be left unconnected or brought out as test points for monitoring.

Orange pins are additional pins added to the package for more functions.

Please refer the datasheet of OSD335x-BAS for their functional description.

The major changes in functionality are listed below. (more…)

All the peripherals supported by the AM335x are also supported by the OSD335x-BAS/IND.  However, the OSD335x-BAS/IND only supports 3.3V I/Os. Please refer to question ‘What are the differences in ball maps of AM335x and OSD335x?‘ for ball map differences between OSD335x and AM335x.

No, you don’t. The AM335x die in the OSD335x is the same as the Die in the discrete TI device.  This means that the Pin Mux will work the same on the OSD335x as it would on the discrete version. There are minor differences in location and position of a few signals. Please refer to question ‘What are the differences in ball maps of AM335x and OSD335x?‘ for ball map differences between OSD335x and AM335x.

The pins of OSD335x correspond to the ZCZ package of the AM335x.

There are 3 use case scenarios for RTC functionality. They are the RTC-only mode which allows all the power supplies except for the RTC to be turned off to save power, RTC timer functionality mode in which the Real Time clocking features are used and RTC disabled mode in which RTC features are not used. Use of RTC requires both software and hardware setups. The hardware requirements of various RTC configurations are shown below and described in detail in the AM335x schematic checklist. Note that RTC-Only mode is not supported by the OSD335x family of devices because of the version of the PMIC (TPS65217C) used to power AM335x.

While there are Linux drivers available for the RTC, the following steps describe the low-level software procedure to enable use of an external 32Khz oscillator for RTC clock input.

Begin with writing the KICK registers to disable write protect to RTC registers.

1. Write the value 0x83E70B13 to KICK0R (0x44E3E06C) register.
2. Write the value 0x95A4F1E0 to KICK1R (0x44E3E070) register.

RTC_OSC_REG (0x44E3E054) register needs to be modified to enable external oscillator clock input. Set RTC_OSC_REG[4] to 1 to select external 32KHz oscillator as clock source and RTC_OSC_REG[6] to enable clock mux of RTC. Note that 0 at RTC_OSC_REG[2] enables the use of internal feedback resistor instead of an external one.

3. Write the value 0x48 to RTC_OSC_REG (0x44E3E054).

The procedure can be verified by either probing the output of the 32KHz (OSC1) oscillator or probing the XDMA_EVENT_INTR1 signal selecting OSC1 as its clock source.

The AM335x inside of the OSD335x family of devices can directly drive LCD panels.  Here is an overview pulled from the AM335x datasheet on TI.com

• LCD Controller
  • Up to 24-Bit Data Output; 8 Bits per Pixel (RGB)
  • Resolution up to 2048 × 2048 (With Maximum 126-MHz Pixel Clock)
  • Integrated LCD Interface Display Driver (LIDD) Controller
  • Integrated Raster Controller
  • Integrated DMA Engine to Pull Data from the External Frame Buffer Without Burdening the Processor via Interrupts or a Firmware Timer
  • 512-Word Deep Internal FIFO
  • Supported Display Types:
• Character Displays – Uses LIDD Controller to Program these Displays
• Passive Matrix LCD Displays – Uses LCD Raster Display Controller to Provide Timing and Data for Constant Graphics Refresh to a Passive Display
• Active Matrix LCD Displays – Uses External Frame Buffer Space and the Internal DMA Engine to Drive Streaming Data to the Panel

(Source: AM335x datasheet)

The MUX_OUT pin of the PMIC (TPS65217C) can be connected to the ADC channels of the AM335x externally on the OSD335x-SM device. The ball numbers for each of the PMIC_MUX pins and commonly used ADC channel are given below:

But, OSD335x (OSD3358-BAS) DOES NOT support this functionality since MUX_IN and MUX_OUT pins are not externally accessible on this device.

Yes, the OSD335x family supports all of the functions of AM335x that is inside the OSD335x.

The AM3358 supports PRUs therefore the OSD3358 supports PRUs.

We plan to support these devices as long as TI continues to support the AM335x device. In fact, we will most likely be able to support them longer than TI will because of our ability to bank die.

In our lab, we have used both the XDS110 and XDS200 emulators.  Depending on your emulation / debug needs, you can also use higher end emulators like the XDS560v2.

If you plan to use debug features like trace that are available on higher end emulators, please make sure that you bring the EMU2/EMU3/EMU4 pins to the JTAG header. If you do not plan to use those higher end debug features, then those particular EMU signals do not need to be routed to the JTAG header.

Texas Instruments also provides a number of different websites detailing information about the emulators that can be use with the AM335x processor, and thus the OSD335x SiP, as well as general inofrmaton about JTAG connectors and adapters:

• Debug Probe Performance Comparison
• XDS Target Connection Guide
• JTAG Connectors
• JTAG Adapters

Linux images from Bealgeboard.org require EEPROM to be programmed with a board ID. The following solutions can be used to overcome this issue:

1. Bypass the checks in the bootloader (u-boot)

2. Use Robert Nelson’s patch to create u-boot that will boot and allow you to program the EEPROM: In u-boot apply the patch:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch#L157-L164

u-boot also uses a device tree that you might need to modify. You should find the u-boot device tress in ./arch/arm/dts It is useful to look through the 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch from Robert Nelson (see https://eewiki.net/display/linuxonarm/BeagleBone+Black) since this patch modifies device trees and can point you to important directories in u-boot.

A more detailed explanation of the above options can be found in this forum post.

Generally, XDS200 connectivity issues can be resolved by updating its firmware.

To update a XDS200-class JTAG debugger connected via USB, using a Windows host is highly recommended. Close any instances of CCS that are running in your system. Open a Windows Command Prompt and issue the following commands:

1. Go to the directory where the utility is installed:

C:\>cd C:\ti\ccsv6\ccs_base\common\uscif\xds2xx

2. Run the configuration just to make sure a XDS200-class debugger is connected and to confirm the firmware revision installed on it:

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0

3. If you have a single XDS200 connected via USB:

Run the following commands in the exact order shown below (the batch file update_xds2xx does this in reverse order, increasing the chances of failure):

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf update xds2xxu 0 xds200_firmware_v1008.bin

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf program xds2xxu 0 xds200_cpld_v1008.xsvf

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf boot xds2xxu 0

4. After that, run the command in step 2 again to check if the correct firmware was loaded.

C:\ti\ccsv6\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0

If connectivity issues persist, please go through the XDS200 Wiki to find out more information.

Power consumption of OSD335x-SM depends highly on usage scenarios. The OSD335x-SM Power Application Note and the OSD335x Power Management Software Control Application Note will give you detailed information about OSD335x-SM power consumption in various operating states.

Other helpful resources are:

1. AM335x Power Consumption Summary: This wiki page provides current and power measurements for common system application usage scenarios. However, these measurements were made for a presently unsupported version of SDK. Updated power consumption data can be found here.
2. Power Estimation Tool: This entails modifying and submitting a spreadsheet specifying processor mode and peripheral usage of AM335x. Login to TI website is required and the results will be emailed to the email address used to login.

All the peripherals supported by the AM335x are also supported by the OSD335x-SM. Please refer to the Ball Map section of the OSD335x-SM datasheet to understand naming conventions of various balls of OSD335x-SM. Also, the OSD335x Family Pin Assignments page gives you detailed information about pin mapping differences between OSD335x-SM and AM335x.

No, you don’t. The AM335x die in the OSD335x-SM is the same as the Die in the discrete TI device.  This means that the Pin MUX will work the same on the OSD335x-SM as it would on the discrete version. There are differences in the location and position of the signals, however. Please refer to OSD335x Family Pin Assignments page for ball map differences between OSD335x-SM and AM335x.

The ORCAD files for both OSD335x and OSD335x-SM devices can be found here.

Yes, OSD335x family runs all Linux distributions supported by TI for AM335x. It is also officially BeagleBoard Compatible so it will run the same Linux distributions found on Beaglebone Family of products.

Here are some good resources:

Texas Instruments Linux Kernel Users Guide

elinux – Building BeagleBone Black Linux kernel

Beyond Logic – Compiling the BeagleBone Black kernel

elinux – BeagleBone Black Debain

These power pins are driven by the TPS65217C PMIC and are used internally to power the AM335x, DDR and other components.  These pins are all connected within the SiP and should not be connected externally.  Optionally, these pins can be brought out as test points for debugging purposes only.  They should NEVER be used to power external components.

The following table shows the minimum set of signals that need to be connected externally between the processor (AM335x) and PMIC (TPS65217C) to use the OSD335x-SM. It also shows internal pull up resistor values, the voltage rail they are pulled up to and the specific pad that was pulled up.

The OSD335x family supports all the frequencies supported by corresponding AM335x present inside. For example, the AM3358 inside the OSD3358 supports 6 Operational Performance Points(OPP). It can run at 300MHz, 600MHz, 720MHz, 800Mhz and 1GHz. These operational performance points are set using the Digital Phase Locked Loops(DPLLs) and MPU, CORE voltages on the AM335x. The following figure from the AM335x datasheet (Table 5-7) shows the OPPs, the corresponding MPU voltage to be set and the frequency of operation of the OPP (Source: AM335x datasheet).

The oscillator circuit for real time and system clock inputs is shown in figure 6-9 and 6-12 in the AM335x datasheet.

The values of components C₁ and C₂ referred in the figures depend on the load capacitance (C_L) specified (more…)

Yes we do. You can find the OSD335x Family Pin Assignments table here.

There are 3 use case scenarios for RTC functionality. They are the RTC-only mode which allows all the power supplies except for the RTC to be turned off to save power, RTC timer functionality mode in which the Real Time clocking features are used and RTC disabled mode in which RTC features are not used. Use of RTC requires both software and hardware setups. The hardware requirements of various RTC configurations are shown below and described in detail in the AM335x schematic checklist. Note that RTC-Only mode is not supported by the OSD335x family of devices because of the version of the PMIC (TPS65217C) used to power AM335x.

While there are Linux drivers available for the RTC, the following steps describe the low-level software procedure to enable use of an external 32Khz oscillator for RTC clock input.

Begin with writing the KICK registers to disable write protect to RTC registers.

1. Write the value 0x83E70B13 to KICK0R (0x44E3E06C) register.
2. Write the value 0x95A4F1E0 to KICK1R (0x44E3E070) register.

RTC_OSC_REG (0x44E3E054) register needs to be modified to enable external oscillator clock input. Set RTC_OSC_REG[4] to 1 to select external 32KHz oscillator as clock source and RTC_OSC_REG[6] to enable clock mux of RTC. Note that 0 at RTC_OSC_REG[2] enables the use of internal feedback resistor instead of an external one.

3. Write the value 0x48 to RTC_OSC_REG (0x44E3E054).

The procedure can be verified by either probing the output of the 32KHz (OSC1) oscillator or probing the XDMA_EVENT_INTR1 signal selecting OSC1 as its clock source.

The AM335x inside of the OSD335x family of devices can directly drive LCD panels.  Here is an overview pulled from the AM335x datasheet on TI.com

• LCD Controller
  • Up to 24-Bit Data Output; 8 Bits per Pixel (RGB)
  • Resolution up to 2048 × 2048 (With Maximum 126-MHz Pixel Clock)
  • Integrated LCD Interface Display Driver (LIDD) Controller
  • Integrated Raster Controller
  • Integrated DMA Engine to Pull Data from the External Frame Buffer Without Burdening the Processor via Interrupts or a Firmware Timer
  • 512-Word Deep Internal FIFO
  • Supported Display Types:
• Character Displays – Uses LIDD Controller to Program these Displays
• Passive Matrix LCD Displays – Uses LCD Raster Display Controller to Provide Timing and Data for Constant Graphics Refresh to a Passive Display
• Active Matrix LCD Displays – Uses External Frame Buffer Space and the Internal DMA Engine to Drive Streaming Data to the Panel

(Source: AM335x datasheet)

The MUX_OUT pin of the PMIC (TPS65217C) can be connected to the ADC channels of the AM335x externally on the OSD335x-SM device. The ball numbers for each of the PMIC_MUX pins and commonly used ADC channel are given below:

But, OSD335x (OSD3358-BAS) DOES NOT support this functionality since MUX_IN and MUX_OUT pins are not externally accessible on this device.

Yes, the OSD335x family supports all of the functions of AM335x that is inside the OSD335x.

The AM3358 supports PRUs therefore the OSD3358 supports PRUs.

We plan to support these devices as long as TI continues to support the AM335x device. In fact, we will most likely be able to support them longer than TI will because of our ability to bank die.