TMS320C6713B fails to run

Katherine Foote

Other Parts Discussed in Thread: TMS320C6713B

We are having an in issue with a TMS320C6713B. Most of the time, our code is executing with no issues; we power up using Host Boot mode and all is well. However, sometimes on power up we program in Host Boot mode (and read back the checksum over the HPI bus and all appears to be well), but the processor appears to never start.

We have checked the state of all HD pins when the reset is released. They all appear OK, including the 'Do Not Oppose' pins in the datasheet.

We have checked the nTRST, EMU0/1 and they are the correct state on power up. The CLK0 pin is also correct.

We have checked the length of the rest pulse. It quite sufficient and appears stable (no extra glitches). We have verified that the reset pulse occurs after the power supplies are stable.

We have altered the power supply sequencing so that the 3.3V doesn't even start coming up until the core voltage is stable. No change.

What are some other things we should be checking? It is very odd in that once the processor does not start on a power up, subsequent pulses of the reset line do nothing.... it is some state on a particular power up that is permanent until we cycle the power again.

Thanks in advance for any support!

over 13 years ago

0 Ralf Koester over 13 years ago in reply to Sam Kuzbary

Expert 1400 points

Hallo Brad, hallo Katherine and all other,

the daily update of testing shows this result:

PCB-1: 0% faults, roughly 60 test cycles (before new init code 30%)

PCB-2: 0% faults, roughly 40 test cycles (before new init code 15%)

It seems really, that the problem has been found!

Thanks to all for working together.

best regards Ralf

P.S.: the wrong code still can be find in the documents of TI!

0 RandyP over 13 years ago in reply to Ralf Koester

TI__Guru* 84110 points

Ralf,

Can you please point us to the documents where you find the bad code?

In a search of my documentation and TI.com, I found the following documents that use the VEC_ENTRY macro:

spra455a
spra489a
spra528a
cslr_userguide.pdf

The cslr_userguide.pdf is the one that explicitly shows using VEC_ENTRY _c_int00 while the others have VEC_ENTRY _vec_dummy. The _vec_dummy cases are not used as an actual reset entry point but as part of a relocatable Interrupt Service Table. The vectors.asm code examples that I found have an explicit reset vector then macros for the other interrupts.

One related thread sounded like DSP/BIOS fixes this issue, so the main concern is with using these four documents as an example for non-BIOS applications. These examples could be written better to explain their limitations (and cslr_userguide.pdf corrected). In my opinion, all four should show valid reset vectors even if they are not intended as reset vectors, since they will all be used as examples and expected to work.

I cannot promise when these may be updated. We may be able to put an article on the Wiki more quickly explaining the correct way to implement a vector table. This is done in our online training material, but a more visible method would be better.

If you found this code in other documents, please list them for us.

Regards,
RandyP

0 Katherine Foote over 13 years ago in reply to Ralf Koester

Intellectual 280 points

Hello Ralf, and all,

I would agree that this has fixed the issue. We have made the same change to our init code as you, and have re-tested boards that would fail 80-90% of the time under temperature stress with the old code that now have not failed after a multitude of attempts with the new init.

To reiterate the solution:

This macro:

VEC_ENTRY .macro addr
    STW   B0,*--B15
    MVKL addr,B0
    MVKH addr,B0
    B     B0
    LDW   *B15++,B0
    NOP   2
    NOP
    NOP
   .endm

should not be used for the rest vector (it is ok to use it for other interrupt vectors). This macro is apparently used due to some misleading TI reference documentation about how to form a reset vector when not using DSP/BIOS (my take from posts in this thread.... ).

The reset vector should contain:

    MVKL addr,B0
    MVKH addr,B0
    B     B0
    NOP
    NOP
    NOP
    NOP
    NOP

where addr is the address you wish to jump to on a reset.

Thanks so much to all who posted in an effort to find the cause of this troubling issue. It is very much appreciated!

-Katherine

0 Steve Conner over 13 years ago in reply to Katherine Foote

Prodigy 210 points

That's great news! I guess then all of our problems were basically caused by using uninitialized memory, though in my case it was entirely my own fault, whereas Ralf and Katherine got some "value added" from TI.

Re the documentation, what we're discussing is a special case where the interrupt vector table is also the bootloader. It is also a sneaky case, since in the development system, the stack is probably initialised by another BIOS or the emulator GEL file or similar, and that erroneous stack push ends up going to a valid memory area.

TI seem to have other documentation, for instance SPRA544, that gives valid code for a reset vector.

I agree with Brad's comment that overwriting reserved areas in the DSP's memory can crash/disconnect the emulator. In other words, it's a debugger that can be defeated by a common kind of bug.

0 RandyP over 13 years ago in reply to Steve Conner

TI__Guru* 84110 points

Katherine,

Please edit your post with the reset code to add five NOPs after the B B0. The 5 delay slots after the B B0 have to be filled with something and you need to have exactly 8 instruction words to fill the fetch packet and maintain spacing to the next interrupt vector.

If you prefer, we can have a Moderator edit it for you.

Regards,
RandyP

0 Brad Griffis over 13 years ago in reply to RandyP

TI__Guru*** 125430 points

Good point, Randy.

Katherine, I already made the edit for you.

Processors

Processors forum

TMS320C6713B fails to run