TMS320C6657: RESETFULL not functioning the same as a power cycle

Could you provide some details on your use case? What sw are you running on the device, how do you issue the RESETFULL?

Best Regards,
Yordan

We are running our own software. I don't expect the software we are running to affect the functionality of the RESETFULL signal.
We are toggling the RESETFULL signal to the DSP from an FPGA.

In that case check that you comply with the timings described in Section 5.7.2 Reset Electrical Data / Timing from the Datasheet. Also make sure you follow the sequence described in Section 6.5.1 Power-on Reset in the datasheet.

Best Regards,
Yordan

Hi
We are driving the RESETFULL for 150ms and we see the RESETSTAT from the DSP as per timing.

We don't have a Power On Reset problem. We only have a problem when we try to reset the DSP with the RESETFULL signal.
When the DSP enters this "bad" state it never recover until we power cycle. i.e. subsequent RESETFULL does not take it out of that state.

I'm running a single core application with full L1P and L1D cache. Half of L2D is configured as cache. Code running from DDR.

Thanks
Dhar

The "bad state" we see is a very slow processing of data.

So after a RESETFULL we are able to reload the DSP over PCIE, and execute our code.

The code I am running is encoding video which requires the cache in order to meet data rate requirements. After we do a RESETFULL we will enter a state where we can no longer process video at the required rate until we power cycle.

So the steps after reset are:
Load a bootloader over PCIE which Initializes PLL and setup DDR
We then Load application over PCIE into DDR
Run

Dhar,

From a digital logic perspective, a reset initiated by RESETFULLz is identical to a reset initiated by PORz.  The difference between the two is limited to the tri-stating of the output buffers when PORz is low.  Whenever PORz or RESETFULLz initiate a reset, all internal logic including test and emulation logic as well as all reset-isolated blocks are forced back to the initialization state.  Also, these resets both cause the BOOTMODE pins to be latched.

You claim that you are seeing different behavior from a power-up versus a restart initiated by a RESETFULLz reset.  Are there any other functional changes to the board during the RESETFULLz initiated reset?  Also, please provide information about your reset control during power-up.  Ideally, we would like to see a scope capture of all resets in both the power-up and the restart conditions.  Also, please confirm that the power sequencing requirements are met and that al supplies are valid and stable AND all clocks are valid and stable prior to either reset-release sequence.

Tom

Dhar,

Have you been able to collect any of the requested information?

Tom

Hi
Sorry, this issue was moved to low priority as we have a few other problems to solve.
We may eventually power cycle the processor instead of reset.
Thanks
Dhar