C6713B only booting half the time

Sean,

There have been several threads discussing boot or reset issues with the C6713. The most recent that I recall working with had to do with an invalid assembly code in the reset vector table location.

If you have not done so already, please take a look at some of those to see they could be similar to your case. You can try searching for "c6713 boot" (no quotes) and "c6713 reset" (no quotes), for example.

Regards,
RandyP

Hi Randy,

I am aware there are several posts, I have made several over the past year r so and I have read hundreds but never found a solution to the problem.

If the DSP is not even accessing the flash to copy the boot code over then how could it be the assembly code that is the problem?

Are you able to tell me what the DSP is doing during phase two of its reset (when the ECLKOT is at 1/8 of the clock input)? and can you confirm that the NMI will have no effect on the DSP at this stage (before it has done its boot from the flash) to try and help us understand what the problem could be.

Many thanks

Sean

Temperature defiantly makes it worse at 30° the DSP rarely starts but at 0° (c) it starts the majority of the time.  Is there any kind of documentation as to what hardware checks if any the DSP does before booting? 

Sean

Sean,

Do you have external resistors on the boot pins or are you leaving some of them to the internal pull-up/-downs?

Can you confirm the heat sensitivity is isolated to the C6713 using some freeze spray or a heat gun?

What does CLKOUT3 look like during the startup process?

What do you see on HOLDn and HOLDAn?

Regards,
RandyP

Sean,

This sounds like there is an issue with one of a few things. I would suggest you take a look at

• Power Sequencing (typically suggest Core first, I/O second, and make sure they hit their rails <1s apart)
• Stable clock(s) prior to de-assertion of RESET
• Length of time between the supplies hitting their rails and de-assertion of RESET
• Noise on power and clocks (keep in mind that heat impacts clock timing)

and report back here especially if you see anything questionable. My guess based on the little I know so far is that there is probably some noise causing issues with the system clock and confusing the CPU or other logical blocks.

To address your specific question about the /8 clock the PLLDIV3 (which is the post-divider from the PLL prior to getting to ECLKOUT) is /2, the PLLDIV0 (pre-divider prior to multiply) is /1 and the PLLM defaults to x7. If anything I would expect you to see the ECLKOUT as your input frequency x3.5; however, the bypass is also enabled by default meaning ECLKOUT3 should be CLKIN/2. The div-by-8 leads me to suggest issues with the clock and/or stability of the part (which again leads me to look at the items I mentioned in the bullet points above).

Thank you both for your reply's,

Tim, the /8 is what is specified in the datasheet under reset timings so according to the data sheet this is what should be happening.  I am already holding it in reset while the supplies stabilise then resting about every 4 seconds if it doesn't output (our quick fix to work with the problem).  My question was more what the DSP is doing during this phase regarding internal checks that might make it decide not to boot.

Randy, I am afraid as we are using a BGA device I cannot access HOLDn, HOLDAn or CLKOUT3 (a big pain i know).  I have a mixture of connections to the boot pins if i am not using them I have left them with there internal resistor, if I am not using them but need to oppose them I have tied them to the PWR/GND rail.  There are some pins that are required to be in specific states during booth that I am using that go to sensors/an ADC or a level shifter.  They do however all go to inputs on the different devices so should be ok I plan to confirm this by removing bits from one of our boards today.  I will also try and confirm the temperature sensitivity is local to the DSP.

Many thanks

Sean

Sean,

The DSP is not doing anything during phase 2, other than some internal logic waiting for the internal PLLGOOD signal to show that the PLL is ready to switch over for clocking the device. The DSP is not executing instructions, just some logic is waiting for PLLGOOD (or whatever the internal name is).

Sean Bedford said:

I am already holding it in reset while the supplies stabilise then resting about every 4 seconds if it doesn't output

What do you mean by "resting about every 4 seconds"? Does that mean the reset signal is being held active that long after the power supplies have stabilized? That seems extreme.

Sean Bedford said:

if I am not using them but need to oppose them I have tied them to the PWR/GND rail

This is not the recommended way to oppose the startup state. at the bottom of every page in the Terminal Functions section of the datasheet is the footnote "To oppose the supply rail on these IPD/IPU signal pins, use external pullup or pulldown resistors no greater than 4.4 kOhm and 2.0 kOhm, respectively."

Sean Bedford said:

as we are using a BGA device I cannot access HOLDn, HOLDAn or CLKOUT3

If HOLDn is sampled low then it will bring HOLDAn low to indicate that the DSP does not own the EMIF pins. In this state, the DSP will never try to use the EMIF pins until HOLDn has been released. This would match the symptoms as I understand them.

Also, going into the wrong boot mode would match the symptoms you are experiencing.

When the DSP fails to boot, can you get a connection through an emulator with CCS? If so, you may be able to determine the state of some of the unknown pins. I would recommend trying the latest version of CCS, in case you are using CCS 3.x, if you are not able to connect with CCS 3.x. Some of the emulator vendors include a good test program that can give you some extra information on the device even when a logical connection does not work. And CCSv5's Target Configuration editor has a Test Connection button that will report some of that same information.

Do you have access to the boot mode pins to allow you to select the Host Boot or Emulation Boot modes? Emulation Boot mode would be best, of course. This is commonly used as a way to help figure out what might be going on.

Regards,
RandyP

Sean,

GP[13] is also HD13. There is a note on page 50 in the Terminal Functions section that says "For proper device operation, do not oppose the HD [13, 11:9, 7, 1, 0] pins with external pull-ups/pull-downs at reset'. So I think you are doing good by removing the drag-down circuitry from that pin.

When you are satisfied with your board, please mark the main answer in this thread with the green button and we will know to stop. I suspect it will be your post above with the new information.

Regards,
RandyP

Yes this is why I was looking at that pin belive it or not I have read the datasheet several times. thank you for your help with this I am extremely relived it is finally sorted.