TMS320C6713B: Chip Enable Doesn't Assert Reliably at Cold Temps

Mike, i don't know of any issues.  What does your IO supply for the EMIF interface look like at the lower temps during boot?

Regads,

James

James, 

Thank you for the reply. What is meant by the EMIF "IO supply" ? EMIF CE current sink/draw or voltage level?

Hi Michael,

Really both.  The EMIF IO is supplied by DVDD 3.3V.  According to the datasheet DVDD IO supply current is typical 75mA.  Is there any issues in the voltage level or current supply capability in the failing scenario?  You said sometimes the CE is asserted "partially".  Do you mean that the voltage level is only a fraction of full swing, or the timing of the assertion is incorrect? This might indicate an electrical vs. functional problem.

The issue could be starting elsewhere, and just possibly manifesting itself during EMIF boot.  Are you able to boot with any other method on the board?  Are you able to connect with a debugger to see boot progress? Can you even connect with a debugger after it fails? 

Can you perform a reset without a power cycle?  Does this work after a failed boot attempt?

Regards,

James

Hi James,

I'll check the current draw for the EMIF IO and re-check the 3.3VDC supply level under both a failure and good boot scenario relative to the CE1 Flash accesses. Note that the flash CE and other CE rise and fall times are very succinct without droop even under the failed boot condition which would indicate stability in the 3.3 supply (unless the flash CE doesn't assert at all which is the typical failure mode).

As I don't have access to the CCA and debugger where I'm at but will see if I can get someone to grab the DSP control via the emulator.

"...reset without a power cycle", we'll give this a try from the failed boot state by pulling the DSP reset low and then releasing. EMIF Boot Mode Flash Testing.docx

Please see the attached for scope shots of the FLASH device reset release (yellow) and CE1 (pink) going to flash. 

Thanks, James.

Mike

"Is there any issues in the voltage level or current supply capability in the failing scenario?  You said sometimes the CE is asserted "partially".  Do you mean that the voltage level is only a fraction of full swing, or the timing of the assertion is incorrect? "

I may have been loose in my description. What I meant is at the moment of failure flash CE 1 is seen to assert (low) properly on time at the start of the DMA bootstrap transfer period and then de-assert (high) before the 1KB boot image transfers completely, as in 1/3 or ½ of the way to completion (partial). 

That fact that the other chip selects are toggling is definitely strange behavior.  It's almost as if the device is not getting a proper reset.  Ensure the reset pulse is as spec'ed in the datasheet.  I think the test by resetting the DSP with the reset signal will be important.  Maybe show the DSP reset relative to the flash reset, to ensure the timing of the flash reset is correct, and that the flash reset is completed before the DSP reset is released.  This will ensure the flash is ready when the DSP starts to boot.  

Regards,

James

I found that very strange. However, I think what's going on there is that at failure the 1KB boot strap was transferring garbage from flash to the DSP's internal SRAM because CE1 did not pull low correctly. That random garbage is then subsequently executed by the DSP after the DMA completes which manifests as as random SRAM and FPGA BMR CE accesses. 

Next Steps:

1. Get the DSP's CE1 to fail. At that point manually pull the DSP's RESET input low and release. 

2. See below for startup timing. Capture the below signals at point of failure and verify the DSP Reset is released 200ns after the FPGA is released. 

Michael, any update here?

James