SGMII link fails, but only on initial boot

Jeff,

Did you make sure it is happening only in the boot? Which is the boot mode are you using to run the application or POST code? How you said, it is failure at  CSL_SGMII_getStatus(). Did you use uart printf to debug? 

If you are running the POST from EEPROM, please find the steps at the README.txt file(Steps to program POST to EEPROM).

Pubesh-

1) Yes the problem only happens on boot.  Boot mode is I2C.   We have no issues in reprogramming the I2C EEPROM with our modified POST program.

2) Yes we're using UART output.  We've added a command-prompt to the POST program, so when it comes up we can re-try the EMAC internal loopback test.  Also we print out error messages, so that's how we know the failure is the bIsLinkUp bit.

3) Re-trying does not unstick SGMII0.  But, as I mentioned, if we connect with the emulator, and reload the POST code (without running any GEL scripts), then SGMII0 is ok and the EMAC internal loopback test works fine.

Could this have anything to do with power domain initialization or timing?  That should be taken care of in POST code, correct?

-Jeff

Pubesh-

We are using I2C address 0x50 when programming the I2C EEPROM.

The key is what is different when reloading the post .out file using the emulator.  Even without running GEL scripts, there might be something happening that I'm missing.

Another idea is to cause code to soft reboot.  When code arrives at main(), is there a way to jump back to the entry-point, and cause everything to repeat, including auto_init?  That would be close to what's happening with an emulator program reload.

Thanks.

-Jeff 

Jeff,

I'll do my best to support you here, but reaching the limits of my expertise with boot related. I will check with Expert for Device Boot on this issue and let you know the reason.

Pubesh-

Ok thanks in advance for asking your boot Experts.

Here are some specific questions:

1) When downloading code in CCS (via JTAG emulator), what actually happens?  Is there a System Reset?  A CPU Reset?  If so, would any SGMII registers be reset?

2) I mentioned in my initial post that our board's power-on (or reset switch) timing asserts RESET, POR, and RESETFULL at the same time, and then releases them in that order, with 100 msec between each one).  Does this sound ok?

3) I assume that none of those lines (RESET, POR, and RESETFULL) are affected by by code download/run using the emulator?

Thanks.

-Jeff

Jeff,

I can give some information for boot.

Boot Startup procedure executed only once during:

1. Power On
2. Hard Reset
3. Soft Reset

• Bootstrap pins are only latched during Power On Reset (POR)
• Default boot parameter table is chosen based on the selected boot mode
• Boot strap pin configuration parameters are updated in the boot parameter table
• At completion, the ROM code branches to the main boot function, using the table to configure boot operation

Please find the more detailed information at KeyStone DSP Bootloader User Guide.

Pubesh-

Thanks for your reply.  To re-iterate, here are the really key questions:

1) When downloading code in CCS (via JTAG emulator), what actually happens?  Is there a System Reset?  A CPU Reset?  If so, would any SGMII registers be reset?

2) I mentioned in my initial post that our board's power-on (or reset switch) timing asserts RESET, POR, and RESETFULL at the same time, and then releases them in that order, with 100 msec between each one).  Does this sound ok?

Can you get some help on these?  Thanks.

Also we found that after power-on boot, if we do a Hard Reset by modifying the RSTCTRL register (as shown here http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/193265/691622.aspx), thus causing a re-boot from I2C, SGMII0 will come up ok.

-Jeff

Rajasekaran-

Thanks for your reply.  The CCS related question is what happens when downloading and running code on C6678 core 0 using CCS.  What does CCS do -- is that a CPU Reset?  After downloading code, CCS says "entry point reached" -- did some C66x code already run at this point?  If I post this on the CCS forum, the answer may be the behavior is chip dependent.

Our questions about reset line timing, and their possible effect on SGMII port condition, are still open.

Thanks.

-Jeff

Hi Jeff,

Could you please start new thread for the above follow up question? I will work with experts to support you.

Thanks.

Rajasekaran-

I have posted it here:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/352995.aspx

-Jeff

Hi Jeff,

I will work with team on this. Thank you.