TMS320DM8168: TMS320DM8168CCYG - Error code 10

Viktorija Cecil

Part Number: TMS320DM8168
Other Parts Discussed in Thread: CCSTUDIO

Team,

My customer needs help with:

We have a batch of Rev E boards we are trying to test (previous was Rev D). The changes between the two were adding a few traces to correct the connection to an HDMI Transient Voltage Suppressor, and addition of a wire-to-board connector to provide 12V to a fan on the TMS320DM8168CCYG.

The Rev D boards work fine. The Rev E boards are recognized by Windows (in this case Windows 7). But the driver won’t load. Windows says nothing other than Error Code 10.

I have gone through the PCI registers in the DM8168 and have found the only difference is the PCS_STATUS Register at 0x51000388. In the Rev D this register reads back as 0x00001333. In the Rev E the register reads back as 0x00001300. The differences are the PCS_TX_EN 11b working vs 00b non-working, and the PCS_RX_EN again 11b vs 00b. It appears as though either Windows or the DM8168 is disabling the TX and RX for both PCIe lanes. Since our driver never starts we have no visibility into the problem with Windows.

I have looked at all of the voltages for the DSP and they are all good. The 27MHz and 32.768KHz clocks to the DSP are also good.

I can run all of our test programs through the emulator so I know the DSP is up and running. It just seems to be a problem with the PCIe bus.

We look forward to your inputs as soon as possible.

Thanks

Viktorija

over 8 years ago

0 Pavel Botev over 8 years ago

TI__Guru**** 170625 points

Hi Viktorija,

What software you are running on DM816x device? Is it Windows?

Are you running the same software on revD and revE boards?

Do you connect DM816x board to Windows PC through PCIe? If yes, do you use DM816x PCIe as RC or EP?

You state that you have check voltages and clock of the C674x DSP, could you please explain how C674x DSP is involved here?

Regards,
Pavel

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

I am the engineer for this board. Viktorija entered the problem into the forum for me after we had a conversation about the problem.

We are currently testing on a Windows 7 machine.

When we found the driver was not starting properly with the Rev E board we put in a Rev D board and it was fine.

The board is connected to the PC through the PCIe as an EP.

I have checked all of the voltages and clocks to the DM8168 and they all looked good. The changes to the board from D to E were very minor and had nothing to do with the PCIe. I have also compared the gerber files from D to E and the only differences were the ones I intended to be there. We are using the DM8168 as a SD/HD video compression (H.264 Encode) device.

The problem looks to be a manufacturing issue (PCB problem or incorrect part). Being a hardware engineer I do not know how to determine where the driver is failing. If I knew that it would give me a clue where to look.

Regards,

Mark

0 Pavel Botev over 8 years ago in reply to Mark7389

TI__Guru**** 170625 points

Hi Mark,

Mark7389 said:
When we found the driver was not starting properly with the Rev E board we put in a Rev D board and it was fine.

Can you provide more info regarding that driver? Is it TI linux kernel driver? Do you have any console log which you can share?

Mark7389 said:
The changes to the board from D to E were very minor and had nothing to do with the PCIe.

Do you use the same DM816x part number in D and E boards?

Regards,
Pavel

0 Pavel Botev over 8 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Mark,

I would suggest you to go through the below wiki pages and see if you will find something useful:

processors.wiki.ti.com/.../AM389x_C6A816x_DM816x_Hardware_Design_Guide
processors.wiki.ti.com/.../DM816x_Design_Resources
processors.wiki.ti.com/.../Debug_Tips_for_DM81xx_Boot_Fail
processors.wiki.ti.com/.../AM335x_board_bringup_tips

We have also HW diagnostic tests, based on CCStudio, which you can use to test your custom board.

support.spectrumdigital.com/.../

DM816x/C6A816x/AM389x EVM Software Resources
Test Code

As a start you can run GEL file and see if everything will run fine there.

Regards,
Pavel

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

We boot this board through the PCIe bus after the Windows system is up and running. It is our Windows driver that is not starting up. The system identifies the board properly because we can see the correct MFR ID and DEV ID in the devices registers. We eventually will boot Linux on the the board using Uboot. We download the system to the DSP memory once our software starts.

Both the D and the E boards use the TMS320DM8168CCYG2.

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

I can run a number of test programs on the DSP using the emulator and CCStudio. These are simple test apps used to debug the original board (memtest, I2C, SPI, etc.). They all work fine. The problem seems to be that the PC identifies the board correctly at startup but our Windows driver never starts. Not being a software engineer I do not know why the Windows driver won't start. I have been searching in vain to find something that will give me an indication of where the Windows driver is failing.

Mark

0 Pavel Botev over 8 years ago in reply to Mark7389

TI__Guru**** 170625 points

Mark,

Mark7389 said:
I can run a number of test programs on the DSP using the emulator and CCStudio.

Do you call DM816x device a DSP? Or when saying DSP you mean C674x DSP subsystem? So when running GEL file and test programs on the DM816x device (Cortex-A8 ARM processor), you do not observe any problems with rev E boards?

Mark7389 said:
The problem seems to be that the PC identifies the board correctly at startup but our Windows driver never starts. Not being a software engineer I do not know why the Windows driver won't start.

Unfortunately I am not aware of your Windows driver, and I can not advice why your Windows driver cannot start on rev E boards. If you can switch to Linux (DM816x EZSDK 5.05) I can be in better help. For Windows support you might check the below links:

Regards,
Pavel

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

When I said I was able to run test programs on the DSP I should have said the the Cortex-A8 ARM processor. My test programs are all fairly simple (memtest, I2C test, etc.) to allow me to test parts of the circuit independently. I have been able to run my test programs successfully on the ARM.

There is something wrong that is preventing the PCIe EP interface to get fully setup. The PC sees the board correctly across the PCIe bus but something is preventing Windows from loading the driver.

I have looked at all of the DM8168 voltages and clocks and they look good. The look the same on both the Rev D and the Rev E boards. I am trying to figure out if there is anything else that will influence the PCIe interface on the DM8168. We have the boot mode pins strapped for PCIe32 for the system I am currently using to test. Are there any other strapping pins, I/O pins, etc. that could be affecting the PCIe interface?

We believe this to be a manufacturing issue. Possibly an incorrect passive somewhere. Maybe a bad board trace somewhere. We have a dump of the DM8168 PCIe registers from the Windows side. The only difference is the indication that there is a problem. I am currently trying to determine if we can see the PCIe registers in the DM8168. If we can then I can check the differences between the two boards. Hopefully there will be a clue there.

We don't have our Linux driver done yet. However, one of our software engineers gave me a dump of the PCIe registers for both boards as seen on his Linux development system. I am currently going through the files to see if there are any differences.

Regards,

Mark

0 Pavel Botev over 8 years ago in reply to Mark7389

TI__Guru**** 170625 points

Mark,

Mark7389 said:
When I said I was able to run test programs on the DSP I should have said the the Cortex-A8 ARM processor. My test programs are all fairly simple (memtest, I2C test, etc.) to allow me to test parts of the circuit independently. I have been able to run my test programs successfully on the ARM.

Have you test HDMI and PCIe? You can also reuse/adjust the test that comes for the DM814x device:

Diagnostics Software

Mark7389 said:
I am trying to figure out if there is anything else that will influence the PCIe interface on the DM8168. We have the boot mode pins strapped for PCIe32 for the system I am currently using to test. Are there any other strapping pins, I/O pins, etc. that could be affecting the PCIe interface?

Besides BTMODE[4:0] pins (AE1/2/3/4/5), you can also check the below pins (which are related to PCIe)

- CS0WAIT/AD2, CS0MUX[1]/AD3, CS0BW/AD4 and CS0MUX[0]/AD8

- PCIe module pins - see DM816x datasheet, section 4.2.11 Peripheral Component Interconnect Express (PCIe) Signals

- PCIe supply pins - VDDT_PCIE, VDDR_PCIE

Make sure that 100MHz difference clock (SERDES_CLKN/P) is active and valid, check also sysclk5 clock.

Check DM816x silicon errata, there are some advisories that are related to PCIe, for example:

Advisory 2.1.1 — Error Interrupt for PCIe EP Mode Not Generated

Advisory 2.1.36 — SERDES Transit Signals Pass ESD-CDM Up To ±150 V

Advisory 2.1.66 — PCI Express (PCIe): PCIe Boot Fails When Connected to Some PCs

As you are booting from PCIe, check DM816x TRM, section 25.8.5 PCIe Boot Procedure

Check also you have valid power-up sequence, see DM816x datasheet:

8.1.7 Supply Sequencing

Figure 8-2. Power-Up Timing

Regards,
Pavel

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

Thanks for the suggestions to try.Sometimes all it takes is someone to point to something that you have looked at a hundred times. We have had a 4 position dip switch to allow for PU/PD on the GS0WAIT, CS0BW and CS0MUX[1..0] since revision A of the board. The default position on the switches had always set these signals to the correct levels. In fact we had never even pulled the protective tape of the top of the switch. On this production run the CM got parts that had the opposite default position. Since I had never had to switch any of the four I overlooked their importance. As soon as I got your list I started going through them one by one. As soon as I looked at the strapping on the CS0... pins it dawned on me where the problem had to be. When I saw the Tech Ref Manual table that showed the settings for the BARs on the PCIe I could see the reason they were not set correctly in the PC.

Thank you again for the help. I was much appreciated.

Mark

0 Mark7389 over 8 years ago in reply to Pavel Botev

Prodigy 170 points

Pavel,

Your messages all have a line:

Note: If this answer solves your question please click the "Verify Answer" button.

I would like to "Verify Answer" but I can find no button to click.

Mark

0 Pavel Botev over 8 years ago in reply to Mark7389

TI__Guru**** 170625 points

Mark,

Glad to see that you have found the root cause. If everything is clear now, could you please verify this thread.

Regards,
Pavel

0 Pavel Botev over 8 years ago in reply to Mark7389

TI__Guru**** 170625 points

Mark7389 said:
Your messages all have a line:

Note: If this answer solves your question please click the "Verify Answer" button.

I would like to "Verify Answer" but I can find no button to click.

This is out of date, I remove it.

Can you check if you have any green button on this e2e post exactly?

e2e.ti.com/.../2322503