I m using floating point DSP TMS320C6713 in a project.
The problem is that our processor halts at power up and this doesn't happen in every attempt. It halts after around 20-30 attempts. we have worked hard to resolve this problem but no solution has been achieved as yet.Kindly tell me the scenarios in which no reset is generated at the DSP.
Your board design or a DSK?
What do you mean by "halts at power up"?
Please describe what an attempt is? Is this power cycling by an external switch or plugging and unplugging a cable or pushing a reset button?
JenniferKindly tell me the scenarios in which no reset is generated at the DSP.
RESETN is an input to the DSP, so this signal is generated external to the DSP and not generated by the DSP.
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
it is a board design.
halting means during power up, no operation is performed by DSP but this scenario is random.
once it takes the no problem of halting is faced.
we are using DC-DC converters of traco of specs 28V, 4A. we have also tried by making current rating 12A but no success.
regulators of 1.2V and 3.3V being used in this circuit.
there is no cable or push button for reset. we are using IC TPS70345 to generate reset signal and 1.2V supply to the DSP.
Another IC UC282 is used to generate 1.2V for FPGA. Is there any problem in this isolated supply.
the problem is that at power up, this floating point DSP C6713 is held
in an indeterminate stage that even it can't respond to reset signal.
Kindly tell any other scenario due to which processor may halt.
You must ensure that the board design has achieved all of the design guidelines in the TMS320C6713 Hardware Designer's Resource Guide and in the datasheet.
Problems with power supply sequencing and reset signal timing come to mind first. Then pull-up resistors on some boot signals, or lack of pull resistors on some boot signals are the next things to check. Clocks must also be operating correctly, and all power supply voltages must be within specified limits.
I want to say that I have been seeing a nearly identical problem on my board using a TMS320C6713B. For any given power cycle, continual system resets through the assertions of the RESETn pin (anywhere from 10 to 50) will invariably lead to the processor coming up in an intermediate state where no code will be executed and it won't respond to further activation of RESETn. I say it comes up in an intermediate state because the processor will output "junk" on the Flash chip select and GPIO pins we are monitoring. (note: Powercycling the processor will restore functionality. Once the DSP has entered the failed condition, subsequent attempts to assert the RESETn will result in identical looking "junk" on the GPIO and chip selects. This "junk" will look different for any given powercycle, but it is always the same for each reset withing the powercycle.)
I'm open to the idea, but pretty skeptical that this is a power supply issue. The reason is that we aren't pulling power to the processor at all during the reset. Is this a problem? We are also asserting the RESETn pin for a long time compared to the minimum specified.
There must be something to this if the OP and I are experiencing similar failures (at least I think they sound similar). This is my first post on the topic, and I would appreciate any support you could give.
There is a good chance that the thread below will help you. Please let us know if it does, or if there is a problem with the link.
TMS320C6713B fails to run
Check that you have the boot mode pins properly wired. The usual configuration has this behavior: RESET causes the C6713 to set all internal registers to default values (including interrupts disabled), use EDMA to copy 1KB from the start of C1 space to addresses starting at 0 in internal SRAM (using default EMIF parameters), and then begin execution at address 0. Unless you're not meeting the RESET pulse or boot mode specifications, there seem to be only two logical possibilities: (1) your ROM at 0x90000000 (C1 space) can't be read using the default EMIF parameters, or the program in the first 1KB of your ROM does not maintain proper control. If you haven't programmed the ROM, you get "random" results. There is a paper on C6000 bootloaders somewhere in the TI documentation.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.