TMS320C6678: Intermittent C6678 PCIE init issue during Boot problem

Hi,

Can you please share which MCSDK version are you using?

Best Regards,
Yordan

Kanae,

This problem report has multiple interlocking issues.  This must be segmented to properly validate robust operation.  The original comment was SPI boot failure and you also mention PICe issues.  Set PCIe aside.  Can you make all boards reliably boot from SPI?  For those that fail SPI boot, is the DEVSTAT register correct?  What are the symptoms of SPI boot failure?  Can these failing boards reliably pass a SPI write - read test?  Is this true at both high and low temp?

Tom

Hi. Thank you for reply!
I would like to answer each question as follows(*).

Yordan: Can you please share which MCSDK version are you using?
*BIOS-MCSDK 2.1.2.6

Rahul: can you confirm that this is in place in the IBL version you are using...
*Do you mean the IBL is in the below folder?
C:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\make\ibl_c66x

Tom: Can you make all boards reliably boot from SPI?
*Yes. 2 of 30 units can boot when they have kept at a high temperature; around 50℃
or at a low temperature; around -10℃.
Or after power "2 of 30 units" on for a few minit, then they are powered off and powered on again.
"2 of 30 units" can boot. This status might be warm the board/C6678
Other 28 units do not have any error for boot.

Tom: For those that fail SPI boot, is the DEVSTAT register correct?
*I will make sure this to my customer.

Tom: What are the symptoms of SPI boot failure?
*When the boards have left for hours in a normal tempareture; around 23 to 35 ℃,
"2 of 30 units" are facing the SPI boot failure.
My customer is comparing OK board's memory browser to NG board's one
at setting "Pci_setMode". The results are as follws.
******************************************************************
OK board's memory browser ; The following valus can be keep.
-g_hModuleGpioLocal
0x0087FA54: 02320000

-g_iBootstatusLocal
0x9987F814: 000000FF

NG board's memory browser ; The following values are cleared.
-g_hModuleGpioLocal
0x0087FA54: 00000000

-g_iBootstatusLocal
0x9987F814: 00000000
*******************************************************************

Tom: Can these failing boards reliably pass a SPI write - read test?
*I will make sure this to my customer.

Tom: Is this true at both high and low temp?
*There are no problems at both high and low temp.
It happens only at normal temp.

Best regards,
Kanae

Dear Sirs,

I have additional answers.

*****************************************************
Tom: For those that fail SPI boot, is the DEVSTAT register correct?
*Yes. DEVSTAT register value is "0x0001A60D".
  PCIESSMODE is RC mode setting.

Tom: Can these failing boards reliably pass a SPI write - read test? 
*Yes, it can pass a SPI write - read.
*****************************************************

Could you please any comment to my first questions?

Question:
My customer has tried the following workaround.

(Original setting)
After BootComplete...
1. GPIO initialized
2. PCIE initialized
3. Other peripherals initialized

(Customer's workaround)
After BootComplete...
1. PCIE initialized
2. GPIO initialized
3. Other peripherals initialized

Is my customer's workaround a logical step?
Is there any sequence for initialization for C6678?

Best regards,
Kanae

Kanae,

You say DEVSTAT is correct.  Value of 0x0001A60D is not for PCIe boot.  It is for I2C boot.  Are you loading a second level bootloader from I2C?  If booting from I2C, the mode bits [9:8] are not valid.

Tom

Hi Tom,

Thank you for reply.
The DEVSTAT is set for SPI boot because my customer system is SPI Boot mode as I posted at first.
When the system is not PCIe boot, is it not set "PCIe enable bit"[16], if the system uses PCIe?

Best regards,
Kanae

Kanae,

You are correct.  It is SPI boot.  I shifted a bit during the DEVSTAT decoding.

You keep asking about initialization order.  As long as you have properly managed clocks and power domains and your driver code has no dependencies, peripheral initialization can be customized.

I still do not have clear confidence that you have segmented to behavior to identify that portion of the start-up that is failing.  Please set PCIe aside.  Prove that you can boot in SPI mode, initialize all connected memories, initialize all of the interfaces except PCIe and verify that this is robust.  Test this repeatedly on 'good' boards and 'bad' boards across temperature and make sure that none of these other entities are contributing to the failures.

Tom