C6657 RESET and RESETFULL problems

Hello Thomas,

The RESETFULL and RESET are different in their functionality. The RESETFULL resets the entire chip and latches the boot configuration whereas RESET also resets everything except emulation logic but it does not latches the boot configuration.

The RESETFULL pin will be driven by the on-board host control and it should not create such DSP locking issue unless there is some other hurdle causing this.

Could you please ensure all the power rails are at their nominal level when the DSP lock occurs ?

Are you seeing any hindrance on core reference clock etc., during DSP lock ?

If possible please share the scope capture of RESETFULL signal when the device gets locked ?

Regards,

Senthil

Hi Senthi,

Thank you for your quick response.

I have just verified the supply voltages with a calibrated instrument, just to confirm that this wasn't the problem.

CVDD - 0.998V
CVDD1 - 1.105V
1V8 - 1.794V
1V5 - 1.495V

Looking at the AC component also shows a very low ripple on all supplies.

I'm not sure I understand your question "Are you seeing any hindrance on core reference clock etc., during DSP lock ?", so could you please clarify.
My clocks are enabled and running constantly before, during and after reset.
The clocks are enabled by a CVDD supervisor when CVDD becomes stable. My oscillators have a 3V3 supply voltage and an LVDS output which is AC coupled via two 10nF capacitors to the DSP. No external termination or pull-up/-down on DSP terminals.
CORECLK - 100MHz
SRIOSGMIICLK - 156.25MHz
DDRCLK - 66.67MHz
PCIECLK - N=1k PD, P=1k PU
MCMCLK - N=1k PD, P=1k PU

I'll try to make a scope capture of the RESETFULL signal (controlled by an fpga, together with the core voltages and send them to you.

Besides the problem with RESETFULL sometimes leaving the DSP in a state where the only way out is a power cycle, one other concern is that the RESET signal doesn't seem to perform a HARD reset as default. The only reaction we see is that some of our LEDs, connected to GPIO24-27 turn on and off. It does not initiate any boot sequence.

I'll get back with the scope capture shortly.

Thomas

Hello Thomas,

"Are you seeing any hindrance on core reference clock etc., during DSP lock ?", so could you please clarify.

I was asking about the status of core clock when the DSP hangs, for that you have answered in your post.

When you use the RESET pin to reset the DSP i.e., hard reset, the boot configurations are not latched and it follows the sequence given in section 8.4.2 Hard Reset in the device data manual.

Regards,

Senthil

Hello Senthil,

you write that the RESET pin does not latch the boot configuration and in the datasheet in section 8.4.2 it says "A minimal device initialization begins to occur". What is a minimal initialization and does this mean that the chip does not perform a new boot sequence according to the originally latched boot config pins?

One of our programmers thinks he may have discovered a different behaviour of the RESETFULL pin with an older version of our software, meaning he thinks it is more stable and maybe doesn't freeze the chip. We however need to test this a little more to be sure, but is there anything that software can do that could cause this fault/behaviour?

Thomas

Hi Thomas,

one other important thing to check is the RESETFULL pulse width. Please make sure it meets the minimum  requirement of being held low for 500 * C ns.

C = 1 ÷ CORECLK(N|P) frequency in ns.

Kind regards,

one and zero

Hi one and zero,

the RESETFULL signal is either controlled via an on-board button or an fpga, and in both cases the reset signal is much longer than (several milliseconds) the minimum 5us requirement.

Thomas

We have now made further tests and it seems clear that software can cause RESETFULL not to function correctly. We have no clue to what causes the problem, but maybe someone at TI can cast some light on it so that we can try and prevent it.

We have a script that triggers the RESETFULL each 10 seconds and tests if the DSP restarts. With one DSP sw versions it works every time and with another version it fails regularly (does not reboot and can only be brought back to life by a power recycle).

Thomas

Hello Thomas,

Thanks for your update.

Could you please explain the difference in SW between the two versions ? I would request our software team to look into this issue.

If possible, please share the project files to reproduce the issue from our end.

Regards,
Senthil