TMS320C6655: POR_N in relates to SYSCLK1/2/..7

 Betsy Varughese 

Hi 

I'm already aware of that, if you look on datasheet page 83 you see that both SYSCLK1 and SYSCLK7  are created after same HW chain contains PLLs and MUXes : 

Therefore, I assume the time it takes to SYSCLK7 to be activated working is the same time it takes SYSCLK1 beginning at the same starting point and this is why I based on SYSCLK7 in my measuring in lab as an indication for SYSCLK1  ?

Isn't that correct to do ? 

Another question : Does SYSCLK7 starts being activated only in depends of POR_N signal  ?

Thanks, 

Ohad

Hi Ohad,

Can you probe CORECLK and DDRCLK and confirm those are clocking before POR_N is released?

Thanks,

Kyle

Hi, 

Yes, already done that in the past, clocks are alive 30ms before POR_N is di-asserted. 

BTW, 

In regard to that issue, I have noticed also that the 1.5v input of the DSP is increased to 1v when CVDD/CVDD1 are on, a lot before the 1.5v is actually activated and it happen exactly when CVDD/1 turns on. 

Have you encountered in the past such an issue that other DSP  voltages are getting up because of internal influence of other voltage who got up ? 

What is the attitude of DSP against such a phenomena, is it forbidden ? Can it damage reliability or behavior of the DSP ? 

Ohad

Hi,

If the bleed through is directly from CVDD or CVDD1 (do those ramp together?) to the DVDD15 rail (or VDDRn) rails then that is not likely to be a problem.

However, if any of the SoC IOs (say related to Hyperlink or PCIe or SGMII) are energized and the bleed is through one or more IOs then that may be a reliability problem.  Can you check if any IO is incorrectly powered before it's corresponding supply rail is on?

Thanks,

Kyle

Hi Ohad,

Searching through related e2e posts, this seems to cover the issue you're seeing:

  TMS320C6678: Power rail bleed-back during power up sequence (from 1.0V CVDD1 to 1.5V DVDD15) 

The same "usage note" is documented in the C665x errata:

 document-pdfAcrobat TMS320C6652/54/55/57 Multicore Fixed and Floating-Point DSP SR1.0 (Rev. C)  

Regards,

Kyle

Hi Kcastille, 

So I understand from you that the issue I reported on is familiar and even already written in ERRATA that "It has been verified that this leakage is expected and has no impact on the reliability of the device".

The main reason I have started this investigation of the DSP RESETs and Power Sequence was because of a loading SW issue. which was that every 6 to 7 cycles of reset and shutting down the dsp and then powering it on, the DSP SW is not loaded. 

It was suspected by our System architecture from previous experience with DSP from that series that the resets sequence even if it is turned on by the recommended sequence can sometimes cause the SW an error and prevent it from loading correct. 

Are you familiar with such issues in which because of resets and power sequence which is done not in a specific way the SW once in a while gets stuck and is not loaded correctly? 

Ohad 

The reason I'm in 

BTW,

Are you familiar with any other root causes for such an issue with DSP that is not loaded after a few cycles of resets? 

Regard the ERRATA doc you sent I tried to understand Advisory24 deals with the reset_n, could you please explain what is CCS and what is the issue there?  

Ohad

Hi, 

Based on I/O before Core it looks ok since we manage to get 1.8v turns up before 1.5v(VDDR) starts. However, if we do Core before I/O then we get the following: 

1.5V starts go up before 1.8v. Is that OK? 

Ohad

Ohad,

The errata above says that bleed-through/leakage flows from VDDT to VDDR, so I would expect to see the bleed through plateau in either case:

RE: boot fail.  What boot interface/media are you using?  Can you observe some amount of progress for the ROM execution + boot loader?   Is software execution handed off from ROM to system boot software?

Thanks,

Kyle

Hi 

The issue observed is not a boot fail - It is a SW loading fail. The boot loader has already passed correct. 

Ohad

Ohad,

Can you elaborate?  What exactly do you mean by SW loading fail?  Where/what is failing?  Do you have software logs that lead up to the fail?

Thanks,

Kyle

The local SW that supposed to be running on the DSP gets stuck once in a while. After DSP had been booted up by I2C, Local SW shall be loaded from PCIE and then running on DSP. It succeeds doing that but after power down and then power up a few times, the local SW loading gets stuck. 

Ohad

Kyle, 

is there a way I can add my peer from the SW group to that thread in order to give more details on the SW aspect of that issue we experience? 

Ohad

Ohad,

Your peer should be able to post directly.  Just email them this URL and that should get them started.

  RE: TMS320C6655: POR_N in relates to SYSCLK1/2/..7 

Regards,

Kyle

Hi Kyle, 

Since CVDD1 and VDDT are powering on in the same power phase as you described and the same regard DVDD15 and VDDR1-4, we connected together the voltages of each phase to be from the same power supply:  

That means the same influence between VDDT to VDDR happens between CVDD1 to DVDD15. 

Is that fine?  

Ohad

Ohad,

Yes that's fine.  The difference is that in the one case the current is going *through* the VDDTn->VDDRn rail.  In the 2nd case there is voltage applied to the DVDD15 rail as a side effect of voltage appearing on the VDDR rail.

Regards,

Kyle

Hi Kyle, 

You haven't answered me on it yet. - I mean my question regard Advisory 24 from the ERRATA - What is CCS? 

Ohad

Hi Ohad,

The e2e thread I pointed to was for a sister device (C6678) and that thread links to the errata doc for that SoC.  Both the C6678 errata and C6655 errata reference the errata "Current Flow Between VDDT and VDDR Rails During Power Sequencing of DSP" ... C6678 calls this Usage Note 18 whereas C6655 calls it Usage Note 10.

Similarly, C6655 documents "Advisory 10 System Reset Operation Disconnects the SoC from CCS Issue"  (same as Advisory 24 on C6678)

To your question:

CCS = Code Composer Studio, which is an IDE (including a debugger) that connects over JTAG to the SoC.  It allows breakpoints, memory windows, etc.  If you're not using a debugger connected over JTAG then this issue shouldn't directly affect you.

Regards,

Kyle

Hן Kyle, 

Fine, then could you please send me ERRATA for C6655. 

Ohad

Hi Ohad,

It's here:

https://www.ti.com/product/TMS320C6655

Along with datasheet, user guides, app notes, etc.

Regards,
Kyle