C6713B won't boot from FLASH when power cycled

Najeeb,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

When "the board is powered up after a while", does that mean it was off for all that time or has it been powered on for all that time? If powered on, was it running successfully until you tried to re-boot it?

My first recommendation is to go to the Wiki link and search for "debugging boot issues" (no quotes). You will find some helpful information for many common issues. After that, you may have more information that you can share about your particular situation to help us help you.

The harder thing you would have to do after those recommendations is to look at the power, clock, and reset signals to verify that they are meeting the requirements in the device datasheet.

One thing that does come to mind is the state of the bootmode pins not being in the right state in time for when RESETN is released. This can happen if RESETN is held low for a short time after the power supplies have reached their proper state. The internal pulls (IPD and IPU) might not be able to get to a valid state in time. You can test this by tacking on external 10K-Ohm resistors on those pins to make sure they are at the desired states sooner.

Regards,
RandyP

RandyP,

Thank you so much for sparing time to reply to my question.

By "after a while" I mean that the device is powered OFF for all that time and then when its powered ON, it doesn't boot. However, if it is powered ON and then if turn it OFF and then quickly back on (after fraction of a second or two), the device does boot up properly. 

As regards timing of power, clock and reset signals, shouldn't it be that TPS70345 meet these requirements as it is specifically for TI DSPs. Also, a similar configuration is working flawlessly on another circuit.

Regarding DSP not reading the status of HD4:3 pins properly, my guess is also the same. Currently the pins are externally pulled up with 33R resistors (strong pullup). Should I replace it with a weaker pull up of 10K?

Is there any register inside DSP that shows status of HD3:4 and other configuration pins? If so, I can connect emulator after an unsuccessful boot and see what was read by DSP on these pins?

Thank you,

Najeeb,

Knowing nothing about the TPS70345, I can make no comment about whether it is guaranteed correct in your application nor about any of the setting or performance of the device.

What differences are there from your other circuit that is a "similar configuration"?

Do you have multiple boards with this problem configuration that you have found to work well, and only this one is failing? Comparing multiple boards is always a good way to find problems.

If you have another board that is working well with the same power/clock/reset configuration, then you can be expecting that you have a board-level problem here or a board design weakness. Both are difficult to debug remotely (over the forum) and will require your attention to details from the datasheet (to verify all signals are pulled as directed, not just HD4:3, for example) and trace captures of the signals we discussed earlier to confirm proper operation.

The more information you can provide here, the better we will be able to help with your debug and move to a solution.

Some of our older DSPs may lockup when boot fails and will not allow the emulator to connect. If it will connect, then that would be a good tool to use. There could be registers mentioned in the datasheet that reflect the boot conditions but I am not positive, so I will let you look for those and reply back if you are not able to locate them. But if you are able to connect the emulator, make sure you do not have a GEL file associated with the Target Configuration since it can apply a reset through automatic functions at Target Connect and change the state of the processor. You will want to have the best chance to see what the PC Program Counter is to locate where the processor is trying to run when the connection is made.

Regards,
RandyP

RandyP,

By "similar configuration" I mean configuration of TPS70345 regulator with C6713B DSP. Otherwise, the two circuits are not same. This one has 1M x 32 RAM on CE0, 1M x 32 FLASH on CE1, CE2/CE3 routed to CPLD. The other one has SDRAM, 256 Mbit SDRAM on CE0, 1 M x 8 FLASH on CE1 and CE2, CE3 routed to FPGA. Moreover, I currently have only one board populated and wanted to make sure everything is fine before I populate other boards.

So it seems I should get other boards populated as well to see if they also present the same problem. If so, I would have to look into other design parameters as you suggested.

One more thing I have observed is that when emulator is connected to JTAG pins, no CE1 signal appears on boot up no matter how many time I power it ON or OFF, after a while or in quick successions.

What type of information would you need from me to further comment on this issue?

Looking forward,

Regards

RandyP,

As per your your suggestion, I went to my test bench and had a careful look at my schematic. I checked all the signals as per "Terminal functions" of the datasheet . Everything seemed to be OK.

Next, I connected emulator and tried to connect it when the device didn't boot (CE1 didn't went low on power up). I eventually connected it to find that it was lurking somewhere at PC = 0xFFFF143xx (something) which is reserved memory location. My first guess was that device is not starting up properly.

Non-Solutions:

So I turned my attention to the reset signal to see its duration. It was 140 msec for both turn ON after a while or turn OFF and then ON. To check if a longer reset will help, I used CPLD to drive ~MR1 (manual reset) signal on TPS to extend reset duration to 480 msec. But to no avail.

Next, keeping in view that if I turn the device OFF and then back ON within a second or two, it does boot up, I went on to issue reset twice at startup. i.e. 480 ms reset followed by reset high for 100 msec, again low for 100 msec and back to high. Still to no avail. In fact, it further deteriorated situation and device failed to boot at all.

So I went back to datasheet to have a harder look.

Solution:

Then I came across "Device configuration" section of the datasheet on page 32 and found the following line:

"For proper device operation of the C6713 device, do not oppose the HD [15, 13:9, 7, 1, 0] pins with the external
pullups/pulldowns at reset."

I checked my schematic and found that I was using HD15, HD13, HD12, HD11, HD10, HD9 as digital outputs. All these signals are IPU by default. These signals were routed to level converter (3.3V and 5 V) through 0 Ohms resistors that was enabled all the time. I didnt oppose these signals with pulldown but I also hadn't pulled them up externally.

By using the scope, I checked one of these signals and found that it was showing around 0V (instead of 3.3V) when I turned the system ON and it was not booting. So I disconnected three of these signals from the buffer (by removing 0R resistors) and tried powering it up. And this finally worked. Now the system boots every time, when turned ON after a while or if turned OFF and then back ON quickly.

I wonder why some of these pins are in undefined state at boot up? Also should I remove the remaining signals from the buffer as well (unfortunately the remainings ones don't have 0R resistors to buffer). Is there any recommendations on how these signals should be routed to buffer to avoid this problem in future designs (e.g. will using pull ups on these lines help)?

Thanks for your time.

Regards

Najeeb,

Great job finding the problem. There are a lot of detailed requirements that can only be found the way you did it, one-by-one.

The only recommendation I know to make is to meet all of the pin requirements of the DSP, so there cannot be anything that drives these pins opposite to their internal pulls. Sorry to only restate what you have already said.

And congratulations on solving it!

Regards,
RandyP