CCS/66AK2H12: GEL file/PSC initialization error

Hi,

this runs on the eval board but on the customer board it hangs mid-way through initialization, waiting for a signal related to SERDES initialization. Is this related to PSC initialization errors?

Yes, it is possible that this is a PSC initialization error. Can you add some debug prints in your example? Or maybe debug the code with step into option in CCS., so that you can see exactly where (in which function) the code hangs.

Best Regards,
Yordan

Thanks, Yordan. The PSC initialization error occurs when the GEL file runs; the GEL file PSC initialization is the same as that which is distributed by TI for the eval board. The GEL file has been modified to accommodate the different SDRAM; this occurs after PSC initialization and works correctly. What do the PSC error messages from the GEL file (mentioned in the original post) indicate?

Another detail which I neglected to mention: when using the eval board and loading a program, the program runs to the entry point (main) and stops. When using the customer board and blackhawk pod, and loading a program, execution does not stop. Instead I stop the processor and see that it is hung at 0x0000_0128, which is a branch to 0x0000_0128. I can run the application by changing the PC to the entry point of the file just loaded and continuing. Does the fact that the boot loader stops at this address indicate some prior error or incorrect setup? Perhaps this is a precipitating event.

The code example, BTW, is the TI example also. This run correctly (no need to change, or even rebuild) when running on the eval board versus the customer board. And we know Ethernet works, and port 0 works, on the customer board, since UBOOT runs correctly. (As is required by the processor, UBOOT runs when the boot mode is set so that the processor boots from NAND flash. Any GEL file bypasses most or all of the initialization, including PSC initialization, when the boot mode is NAND flash).

Thanks,

Tim

Hello Yordan,

I tried this yesterday. The normal timeout is 2000; I had doubled this. There was difference in the reported status during GEL file initialization.

I may try to change the order of the two items which fail to initialize.

Thanks,

Tim

I introduced delays in the GEL file before and after the calls that set the PSC for domains 9, 29. The delays were GEL for loops that count to 200K. This had no effect; I still get the 2 errors.

Then, after connecting, I reran the Set_Psc_All_On script from the pulldown menu. That also failed with the same error messages. So, re-running the script had no effect.

Changing the order (moving the two inits that fail up-front), adding delays, increasing the timeout: none of these worked.

Yordan, these PSC states obviously mean or imply something; is there any information you can provide regarding why initialization of a PSC fails? The state of pd2, md9 is 4; the state of pd29, md50 is 8.

Thanks,

Tim

Hi Tim,

Let me have a look at this.

Best Regards,
Yordan

Thanks, Yordan.

Is there a device ID register I can interrogate so that I can confirm part#s, revs of the Keystone II? Both cards have heat sinks affixed to the parts.

Tim

Yordan,

Thanks. I am running on an H14, not 12, so I had mischaracterized this when I made the initial entry.

The goal here is to get the ethernet example to run on this board, so commenting out the PSC enables for 10gb ethernet, while it may keep the GEL file from complaining, will not allow ethernet to run.

Also, since uboot runs and can access the network, I've looked at the PSC module status regs after uboot runs, and compared them to the module status regs after the gel file runs. There are some differences which I am trying to understand/resolve.

I note that even though I commented out the GEL file line that initializes the PSC_DEBUG module, when the GEL file runs the status for this module is 0x31f03. That's probably just because I am using the pod (and have to use it) to dump these regs, whereas when I ran uboot I simply dumped the registers using the md.l command.

When I run the ethernet test, it never gets past CSL_SerdesWaitForSigDet(), apparently waiting for something to happen that is not going to happen. I can stop and step through this; it is waiting for initialization to complete but that never happens. I was thinking/hoping that the PSC complaints from the GEL file initialization were the source.

What other items might cause serdes to fail to respond?

Regards,

Tim

Tim Cooper1 said:

I see that when the customer board initializes, the GEL file reports:

Set_PSC_State... Timeout Error #03 pd=2, md=9!

Set_PSC_State... Timeout Error #03 pd=29, md=50!

What causes this, and what would the effects be?

From looking at the Power Domains and Clock Domains sections of the 66AK2H14, 66AK2H12, 66AK2H06 datasheet  SPRS866G:

a) pd=2, md=9 is the Security Accelerator. The Security Accelerator is enabled / disabled according to the ordered part number. The timeout error enabling the PSC for the Security Accelerator probably means the Security Accelerator is not enabled in the device. From the documentation I can't see any device register to read if the Security Accelerator is enabled or disabled. The device marking should indicate if the Security Accelerator is enabled or disabled.

b) pd=29, md=50 is the 10GbE, which is only in the 66AK2H14. The timeout error enabling the PSC for the 10GbE probably means the device is not a 66AK2H14. From the documentation I can't see any device register which determines if the devices is a 66AK2H14, 66AK2H12, 66AK2H06. The 66AK2H06/12/14 Silicon Errata SPRZ402E lists the same JTAGID register values for the 66AK2H06/12/14 devices.

Does the customer board need to use the Security Accelerator and/or 10GbE?

From your description wasn't sure if your application is using 10GbE or 1GbE.

Thanks for the information, Chester.

The customer board successfully runs uboot, and establishes a network connection under uboot. So we know the ethernet interface works on the customer board.  Under uboot, the board initializes, sets up ethernet, and pings/responds to pings.

Though I can't see the markings on the top of the SOC, the processor card incorporates an 88E1111-B1 PHI. I see this part is a 10/100/1000 transceiver (so, 1Gb?).  This is the same part used on the eval board schematic.  BTW, the BOM for the eval board shows a TMS320TCI6638.  However, the BOM and schematic for the eval card are old, and I am unable to see the top of the part to confirm the part number.

The SA is not needed at this time.  The immediate objective is to get the TI ethernet demo running on the card;  if it used the SA on the eval board (which works) then we would want it to use it on the customer's board.

Note also that the GEL file for the ARM enables all PSCs, even those marked "reserved" in TI literature. 

Thanks!

Tim

Tim Cooper1 said:

The SA is not needed at this time.  The immediate objective is to get the TI ethernet demo running on the card;  if it used the SA on the eval board (which works) then we would want it to use it on the customer's board.

Assuming you mean the NIMU_emacExample_EVMK2HC66BiosExampleProject or NIMU_emacExample_EVMK2H_armBiosExample examples they make use of the 1GBE Ethernet subsystem, and don't use the Security Accelerator.

Tim Cooper1 said:

When I run the ethernet test, it never gets past CSL_SerdesWaitForSigDet(), apparently waiting for something to happen that is not going to happen. I can stop and step through this; it is waiting for initialization to complete but that never happens. I was thinking/hoping that the PSC complaints from the GEL file initialization were the source.

The CSL_SerdesWaitForSigDet() function is reading the PLL_CTRL - PLL Control register (at address 0x0232bff4) defined in the KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide. CSL_SerdesWaitForSigDet() is waiting for a signal detect signal to be set for for a lane.

The CSL_SgmiiDefSerdesSetup() function in ti-processor-sdk-rtos-k2hk-evm-04.01.00.06\pdk_k2hk_4_0_7\packages\ti\transport\ndk\nimu\src\v2\nimu_eth.c attempts to enable SGMII SERDES lanes zero and one, which on a EVMK2H are connected to the 88E1111 Ethernet Phys for ports 0 and 1.

Can you confirm:

a) How many 88E1111 Ethernet phys are fitted to the customer board, and which SGMII ports they are connected to the Keystone II SOC?

b) When the program stalls in CSL_SerdesWaitForSigDet() what is the lane_num parameter?

If the customer board doesn't have two 88E1111 Ethernet phys connected to the Keystone II SOC SGMII0 and SCGMII1 ports then the CSL_SgmiiDefSerdesSetup() function will need to be changed to only enable the SGMII lanes which are connected to the 88E1111 Ethernet phy(s).