Start Problem after HPI Boot with C6713

Ralf,

Since you made a link to here on a similar post I will include a link there for users who find your question to be relevant to theirs. That thread is TMS320C6713B fails to run. Some of my comments here may be duplicates from the other thread, but I did not want you to have to search both to find what is relevant to your post.

This is not an easy task, and it is hard to try to explain what things to look for when there are so many possibilities. It would be nice if we could tell you immediately to do something like re-solder the TRSTn pin or replace the external resistor on the RESETn signal, but that is not likely in a case of remote debug like this.

Please take a look at some of the helpful documents we have written for hardware issues. In the TI Wiki Pages, search for "hardware debug" (no quotes) and also for "checklist" (no quotes) to find some pages with helpful information. You might try searching on C6713 terms also. The TMS320C6713 Hardware Designer's Resource Guide has good points to consider from the design side and the debug side; I recommend you look at both sides as part of this debug process.

The datasheet has specifics on power sequencing and voltage levels and clock & reset requirements. All of these must be met as specified there. It is a tedious task to go through checking every pin, but that is what you have to do. You have already gone through a lot of this and ruled out a lot of things.

Do you have access to re-work facilities for your boards? One thing that must be ruled out for something like 4% drop-out is the possibility of a board manufacturing defect. One way to help isolate the problem is to swap the DSPs between a working board and a failing board, then find out if the problem follows the DSP or if it follows the board or if it goes away. This may be costly if you have to send the boards out for the re-work, but that is a trade-off between that expense and your time in debug.

Can you wire in an external bench power supply to see if a strong and clean supply will avoid the problem? You can control the power sequencing fairly well this way, although there might be a problem with the time duration between supply rails. It is at least one thing to consider which has helped in the past on some other designs.

Ralf Koester said:

Different data codes

What does this mean?

Ralf Koester said:

The EMIF and PLL Init Function is called in every case after CslInit() in MAIN.

Do you mean these functions run on the DSP but the DSP is not running? I am confused.

Ralf Koester said:

When connecting the emulator the data in the Memory of the C6713 seems to be correct (checked at adress 0x0000, there is always to find the jump to c_int00()!

Have you tried to compare all downloaded memory contents in addition to this one jump at 0x0000?

Ralf Koester said:

What is solving the knot after “Connect” with XDS Emulator?

Which version of CCS are you using? Which JTAG emulator are you using?

When you do the Target Connect, there can be a GEL function that calls a sequence of commands. One of those commands could have an effect. Or just the operation of the Target Connect could affect the DSP. Remove the GEL file before doing the Target Connect and see if you get different results.

Please keep us posted on your progress.

Regards,
RandyP

Randy,

I'm now in contact with Wei Guo, Application Support Engineer fromTI's European Customer Support Center.

But first to your questions:

with the data code I meant the producing code on the chip, at least there are different numbers on them.

The EMIF and PLL initilization is of cause only running, when the C6713 is starting correct.

We have added a Verify-Function during HPI Bootload to the C6713. This is done by an XC167, booting alway works correct.

When I connect the emulator XDS560 from TI I can see at every memory area the correct code. By now the jump on adress 0x0000 to the c_int00()!

But the C6713 is not starting.

We use an CCS v3.3, and a XDS560 emulator, model XDS560POD from TI!

There is no GEL load when connecting the target, as far I could see.

Here are the informations I sent to Wei:

12-21-2011:

Hallo Wei,

this morning I could connect my XDS560 after a “Start-Fail” of the C6713 and I checked the

DEVCFG-Register (0x019C0200) and it shows “0x01000BAD”!

(see attached *.jpg)

12-20-2011:

Hallo Wie,

here I have add. information:

The CSR register delivers 0x02030103 after the start, read out with the XDS560!

The DSP is a TMS320C6713BZDP

The Revision ID described in the ERRATA-Sheet on Top of the DSP is C20-91P0C38

best regards Ralf

The DEVCFG register (0x019C0200) contains after connection with XDS560 “0x01000000”!

I attached the design of the JTAG Connection and the HPI-Bus!

to 1. all boards have 2 DSP’s C6713, the 2^nd is always starting perfect, we changed the DSP’s on 2 boards and the problem remained.

               (….. with the Test-Firmware the problem never occurs!)

to 2. we will check the errata sheet, as I wrote the silicon rev. no. is always 3!

to3. the emulator is an TI XDS560 POD serial-no. 033709700B

to 4. which Bit of the DEVCFG Register should I check?

Ralf,

The HPI bootmode is quite straightforward but it is not easy to track the problem . If DSP does not come up it is either a HW problem (HPI timing, Power supply, Power up sequence ...etc) or a SW problem (the code written does not contain _cint00 to execute from 0x0 to the starting point of the code, ...etc).

a) As far as I remember HPI boot:

For HPI boot: once the HPI has written code/data to memory HPI writes to the DSPINT bit. This should start execution meaning that the CPU will start to execute at address 0x0.

- When using CCS I think that the emulation SW drivers will write to the DSPINT as well (see page 98 of the C6713 datasheet) which could explain why when CCS/JTAG is connected then CPU starts always to execute after HPI boot.

b) Some tests:
- One test that could be done is that host can read back the value of the HPIC HPI register WITHOUT CCS being started to ensure that DSPINT was effectively written. This would tell if the host successfully wrote to DSPINT.

- Also try the MOST SIMPLE code (like a while(1){} loop) located at 0x0. This loop in ASM would be in the vector table itself). This would help to narrow down further.

Hope it helps.

Anthony

Hi Ralf,

I am still having what appears to be the same issue as you.  Have you made any progress that you'd be willing to share?

Best regards,

Katherine

hallo Katherine,

not really, because we closed over chrismas. Have you tried to contact your system after a "Start Failure" with an emulator, as I described?

Look what the "Memory-Window" shows in the DEVCON Register at adress 0x19c0200!

I will now check again the hardware Pins, and will try to read back the HPI Configuration register, to what the DSPINT Bit is doing.

Because we have the problem only with 4% of all boards, the recommendation from TI was to change the DSP's from a good an a bad one.

But thi is not so easy because we do not assemble the boards ourselves.

I will keep you in copy when we have progress.

best regards

Ralf

Hi Ralf,

Our DSP code was actually written by another engineer and finished/debugged/verified well over a year ago - I am just working on the downloading of the code on my side of the software (which does work most of the time)....  As such, I'm not super handy with the emulator toolset.  I am going to try and read the DEVCON register to see if I have the same results as you.  No comments on the "BAD" portion from TI?

I have read the HPIC register and confirmed that the DSPINT bit is 0, and then 1 after we set it.  But...when we see the failure, we don't seem to execute any code (and over the HPI bus, we've read back what we programmed and it is correct).  One of the first things the code does is set up the PLL - which causes a current increase as the PLL turns on... this never occurs in a failure case.

It seems that our problem is more evident on a board that has been sitting for a while powered off, or - even more likely -  on a board that might be in a cold chamber powered off.....  We have been digging into our voltage supplies, thinking that a change in capacitance over temperature on our voltage line might be the issue somehow - but it does not look like we are violating the specifications.  We've not yet been able to find an external voltage level that varies from a failure to a successful start....

Out of curiousity - are you using the -300 part?  We are, as well as the ZDP package.  Very difficult to rework to change out a DSP part....

If we come up with a solution, I will be certain to let you know as well!

Best regards,

Katherine

Hallo Katherine,

I follow your communication in e2e forum with Randy and Steve with high interest.

Your detailed descriptions shows, that our problems are nearly the same.

The diff. is, that we have 2 DSP's C6713 connected to the same JTAG, and the second is always working properly.

To your question: we have the 225MHz version of the chip, exct TMS320C6713BZDP!

At the moment I'm in contact with Wei from European Customer Support Center. This is his last answer:

Thank you for your reporting.
Default state of the DEVCFG register (0x019C0200) after device reset is given in the data sheet.
It is strange that just some bits of a register are shown as bad and not the entire register.
According to the silicon errata sheet if 1 is written to bit 0 of DEVCFG, a few pins listed
in Table 2 of SPRZ191j are loosing their internal pullup or pulldown resistor
and external resistor (10kOhm) must be added.
Please check especially TRST, CLKIN, CLKOUT3 etc.
For more information on this please refer to silicon errata sheet SPRZ191j available at: http://www.ti.com/litv/pdf/sprz191j

Best regards Ralf

Hallo katherine,

I forgot a main thing yesterday. In our both C6713 (they are booted both via HPI) we have

different firmware systems. In the "Fail"-DSP we do not use the TI Bios, in the other one

which is always starting correct we use the TI Bios!

Do your Firmware use the BIOS?

I haven't any hints until today from TI, if there are some important details in the BIOS-Startup!

best regards Ralf

Hi Ralf,

I am trying to determine whether or not we use the TI BIOS - at this point I am uncertain but am trying to find out from the developer.  Did you determine if the BIOS had any effects?

I do have one new piece of info though - we are unable to connect the emulator when in our failed state.  We can connect normally, but once we are in our locked up state, the emulator will not even connect.

Also - in our working state and non-working state, I did read the contents of the DEVCFG register over HPI - and we always saw the same value 0x01000000.  From what we can tell, the HPI bus is always working fine.

Best regards,

Katie